Rapid Fire Commits

How many commits are good?

I am quite obsessed with making as little commits as possible.
I usually tend to commit everything at the end; and in case of fixes, amend commits. If I need to make a change after a code review, I might make a new commit, just because it will be simpler for the reviewer to follow the changes, but sometimes, I might just amend the commit again.
In reality, this is not my favourite approach. Often, a single story will require different kind of changes, for instance a preliminary refactoring and then a functional change; then, I would like to separate them into two different commits as well. However, this is not something I am always able to do, because often follow-ups are interleaved, requiring complex history rewrites in order to keep them separated.

Another pattern I have seen is to make a lot of commits. There may be several reasons for that: to put bookmarks during development, to execute tests on the CI, to ask for a review, or even just asa way of creating a trail and a backup.

Being obsessed with commits, I am not a fan of this second approach – to be polite.
But actually, there’s also another reason. Splitting a change into a long series of commits makes history analysis much harder. Especially, it makes difficult to understand why a change was done, and what were the other related changes. Yes, it’s always possible to reach the issue tracking system; but that might not contain all the information, or might even go away (e.g. in case of migration).
A good source control history is extremely important!

Lately I see more and more people using the “squash and merge” compromise: push a lot of commits, but then squash them at the moment of the merge to main.
Personally I don’t like using it on my own because then, when deleting my local branch, I get a (useless) warning – and then I always feel the need to check if I didn’t forget anything.
However, it is a practical solution.

Finally, I still fel like pushing small changes is a bad idea. It will use a lot of CI resources, which are usually limited, leading to buildups in the build queue, and possibly higher operating costs.

Sidebar: IntelliJ users can enjoy the “local history” feature, which is a quite good way to “go back in time” in case something wrong happens. Personally, I like it a lot, and use quite often. Sometimes it’s a bit complicated to understand, but it never failed me to solve cases where I feared losing hours of work!