Atomic Commits

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.