Atomic Commits

A few days ago I replied to this tweet:

Squashing multiple one line commits into meaningful atomic ones?

— Barry (@DrBazza) May 28, 2020

My reply was in jest, but did make me think a little bit more about what atomic commits actually involve.

My (private) github profile never looks like this:

There are two scenarios where I squash commits.

Feature Development

If I am developing a new feature for some code locally, within my fork or private repository, I will commit frequently.

Most of the time I tend to try and commit when a small change compiles, and tests pass.

Very, very, infrequently, I may commit broken code with a suitable commit message, usually because it is a somewhat larger change and to ensure that I don’t accidentally lose any of that code (e.g. git clean, git reset etc.).

Finally, towards the end of a development cycle, I will squash those commits together to form a muich smaller number of logical, discrete, and atomic commits that implements a feature. This also helps me greatly when I use git bisect to diagnose those occasionally difficult to find regressions.

Feature Publication

When you merge a PR in github you are given the opportunity to squash your commits further. At this point it is generally a judgement call, or an agreed process whether PRs are squashed.

For larger projects with a wide range of developers, squashing PRs makes sense for precisely the same reasons. Atomic commits of features are much better than when it comes to identifying bugs and regressions in product behaviour.