Since there are many opinions among git experts as to "how often should a commit be made?" we would like to contribute an opinion informed by modern tooling.

We propose that one commit should include only enough change to dash off a commit message that serves as an ad hoc "artifact of intent." Since it's easier to discuss things that have labels (shakes fist at Twitter's alter-ego), let's call this definition of commit strategy "minimalistic committing."

linkVs. Squash Commits

There is a contingent of programmers who advocate for the opposite of minimalistic committing: squashing commits. Perhaps the best argument for combining commits is that, if you're a auditing work by perusing a commit history, the more work gets stuffed into one commit, the better. In this world, "a commit" is tantamount to a "pull request," in that it's "what the reviewer needs to review."

With modern tooling, there is much less benefit than there once was to optimizing git commit history. If one wants to review groups of historical work, pull request history is already optimized for showing a history of what changed and why -- on the 1-5 day scale (usually a "manageable to review"-scale).

linkPull Requests and Commit Groups summarize units of work

If one wants to review work prior to a pull request, commit groups are your friend in the work grouping business. They can be grouped by configurable date & criteria. And you can always navigate back through the Commit Activity Browser to see patterns from previous eras of work.

With adequate tooling, commits can be grouped to whatever dimensions are expedient for the reviewer -- smaller or larger, by those that involve a migration, or a dependency change. I believe this negates most or all benefit from squash-adjacent commit strategies.

linkMinimalistic committing optimizes blame history

The benefit of minimalistic committing is that it allows commit messages to be more targeted to the one specific thing that changed in the commit. In tools like Gitlens, and GitClear's PR tool (on line hover), every line is summarized by the last commit message to have changed it. If a commit is supposed to combine more than one day of work, that figures to be a lot of information that will be included in the commit message. So, the user trying to understand why the change happened is going to be on the hook for more reading.

Will the "more reading" illustrate additional context? Yes, if the committer is lazy in writing commit messages. But, spoiler: all humans are as lazy as we can get away with. Writing one commit message per day means that you get one shot to be diligent. Writing 10 commit messages per day gives you 10 opportunities to be lazy. But, in the latter, at least you are guaranteed to write at least 10 things about "what you changed and why."

And, again, tools like Commit Groups will automatically aggregate commit messages, so if you write 10 things about the day, they will be collected into one summary of the day's changes and their rationales.

linkConclusion: Minimalistic committing benefits

Historically, there have been good reasons to prefer that lots of work is packed into each commit, to keep each unit of git commit history substantial (hypothetically, to reduce likelihood that the code subsequently changed). With 2020's tooling, there are more reasons to prefer minimalistic committing than in previous decades.

linkPostscript / Minimalistic Committing example

As illustrated above, there is no single right answer to how commits should be authored. But here's a snippet of the author's recent commit history as an ad hoc demo of what minimalistic committing might look like in practice:

Each commit has 1-5 items complete, plus incremental summary as needed to add baseline context.