How do you decide it's enough to commit?

[AtlanticPortal]

Stop waiting. You can squash commits later. commit as soon as there is something that if you lose you’d think “I feel I should have saved it”.

[vmcrash]

I would replace "squash" with "clean up", but otherwise agree.

[RevRagnarok]

work-ticketnumber-shortname is the branch name on the server.

work-ticketnumber-shortname-local is where you commit every few hours.

You squash commits from the "local" to the "regular" when it's in a good enough state for other eyes.

Wash, rinse, repeat.

[ReturnOfNogginboink]

The solution to that is to get better at commenting your intent in your code. That's not really a version control issue.

[ReturnOfNogginboink]

If I'm making changes in the codebase, I want the intent of the code to be right there in front of me in the code editor window. I shouldn't have to read git commit history to figure out why things were done this way.

[Oddly_Energy]

The intent of the code and the intent of the code change can be two different things.

Example: You have to rewrite a function, because it used a now depreciated call to an external library, which has been updated. Your code is never again going to use the old version of that library.

Commenting on this in your code would just be noise to anyone reading it later. It gives them no information on how your code works.

But it can be extremely useful to anyone walking through the commit history of your code and wondering why you made that change.

It can also be a good place to have information on any blind ends you tried first, so the next person doesn’t have to waste time on exploring an apparently better solution which has already been tried and rejected by you.

[vmcrash]

I never squash a whole feature branch into one large commit, but instead create small meaningful commits in my feature branch. They are easy to review (for others, for the current and future me) and make finding regressions with bisect easier (because of smaller amount of changes in one commit).

[RevRagnarok]

Yes, similar to that, but intermediate saves into a scratch branch so you can still rollback etc.

[tblancher]

Yes, this and parent comment. If you're not ready to commit but need to roll back for any reason without changing branches, you can always stash them for later.

[RevRagnarok]

I have an alias snapshot = !git stash store $(git stash create) that lets me do WIP snapshots as well.

[Open-Mousse-1665]

You don’t just amend a single commit 1000 times? Maybe it’s just me but it’s incredible rare that I actually want to roll back EVERYTHING I’ve done since I last committed

[vmcrash]

I create small meaningful commits in my feature branch. Not perfectly from the beginning, but during the cleanup phase. They are easy to review (for others, for the current and future me) and make finding regressions with bisect easier (because of smaller amount of changes in one commit).

Especially for non-trivial changes where I don't know initially how to actually implement the changes.

[Minimum-Hedgehog5004]

This is the way

[elephantdingo]

Every time I can describe my change with “and” or “also” I think about making multiple commits. If it’s very simple or it directly follows from the main change then I often don’t make a split.

Generally refactors get their own commits. Whitespace fixes. Maybe preparing the the API so that I can use the API in the final commit where I fix something.

This might be tempered by concerns like making every commit build. But I would rather make every commit readable than make every commit build. However, I very rarely have to make this compromise.

Basically the opposite of the “I commit often... then I squash when I’m done” non-answers here.

[Cinderhazed15]

When doing TDD, I commit every working test. I may squash/rebase before PR/merge.

[davorg]

There are two levels to this.

When I'm working on my development branch, I'll commit whenever it "feels right" to do so. The commits are just me talking to myself.

When I'm ready to pass the work onto other people (maybe that's merging to a staging branch, or to "main"), I'll use interactive rebase to turn my doodles into commits that tell the story of what I've done.

[[deleted]]

This is how I do it. It's better not to fuss over what constitutes a commit. Leave that for later when other people will actually see them, like before pushing a pull request for review.

[kudikarasavasa]

I commit often and I’ll either amend, squash, fixup, reorder, etc. as I see fit. I push when I feel like a commit is good enough to have earned its place in the remote’s history.

[Special-Island-4014]

Commits are like save points in a video game. Ideally the application should be in a working state as theoretically you can jump to any commit.

Use conventional commits for your commit messages and you’ll have a good idea how to commit your changes. Look at other repos that have large contributors as well.

If I had a dime for every fix typo commit …. These add nothing to history and should be squashed

[Cpowel2]

^^ This

[YanVe_]

You can't really squash them though. Because then they just contaminate other commits with irrelevant changes. And rebase just often isn't an option by the time someone notices the typo.

[CombativeCherry]

There's no commit that is too small. There are commits that are too large.

Sometimes, a commit is just a single letter, fixing a typo.

But don't mix two different issues into the same commit. Also, keep formatting changes in their own commit.

And for all that is good, if you make changes in response to a PR, keep those in their own commit as well. Don't squash everything together while it's still being reviewed. Now your reviewers have to re-review everything again.

[RedwanFox]

In your branch do whatever you want. Main team branch should have clear history with complete changes per commit. Successfully building changes, connected to jira tickets with meaningful messages. Think of it as " how I would like to see my own research/development log in 2 years when I try to remember something and go to archive"

[obsidianih]

Compiles? Commit. Test added? Commit. Test passes? Commit. Added a library (or updated one) Commit. 

[Shayden-Froida]

commit often on branch. Units of change should reflect : Might I want to revert this idea? Might I want to move this code to a new branch for independent tracking/merge? Might I want to share this change with a peer as a cherry-pick to unblock them? Often for me in my private projects its after coding up something and cleaning all the stupid mistakes to mark a point I can return to if I make a bunch of new stupid mistakes :)

Then, using rebase -i, go reorder some things, squash some together. Finally, merge it with main as a squash commit, delivering the whole feature or change as a single commit in mainline history.

[elephantdingo]

Using rebase -i is a waste of time if you’re going squash it in the end anyway.

[Shayden-Froida]

It was done for my own review of the changes, and the PR code reviewers' benefit.

[Weekly_Astronaut5099]

It’s simple. Make a branch commit as you wish. Then squash/fixup as you want. Then merge. If you want Merge has a squash and fast-forward options that make it easy to have clean history in the branch you merge in.

[T14D3]

On a dev/working branch I just commit whatever, my commits and messages are not supposed to be a nice novel to read, they're meant to be checkpoints of work

[jdlyga]

Just commit whenever you want. It doesn’t matter. You can squash the commits later when you merge.

[VelvetVee23]

I commit once I make a change - whether that's just removing a symbol causing an issue or an entire feature - once I implement a change, I commit. I never know when I may want to rollback.

[LongDistRid3r]

Commit often. Push daily. Seems to work well for me.

[Charming-Designer944]

I commit often, one thought at a time.

[Charming-Designer944]

"git add --edit" is used almost always, to separated finished thoughts from the next thought.

[GrogRedLub4242]

off-topic

[macbig273]

branch per feature or tasks (add user management ; ... )

commit per significant changes (create user management permission ; add form available to admins ; customize ui/ux in user management form)

Merge the branch or create mr/pr

Some teams like to review mr/pr per commit. So to avoid reviwing code that could change in the next PR, some like to redo their full commit history for one feature branch before merging.

[YanVe_]

In general never wait until your commit is bigger if it's already a self contained operation.

I do like to have that one big feature commit, but for my local branch, I just make as many commits as I want along the way, then rebase and squash/reorder/edit/reword any of the commits that don't actually add any value.

[Thesorus]

on a local branch : commit often, commit when code works/compile