A note on my stance on squashing

.txt

There are situations where squashing commits is not favourable and is an anti-pattern.

Squashing is necessary when a series of commits represents an atomic unit of work, where an atomic unit of work is any work which if broken into two or more independent commits would render either or both of them functionally incomplete. as an extreme example, changing a single global variable name across two commits would likely break the first commit and so the two commits should be squashed. They should also be squashed because the two commits are thematically one (although thematic unity can be relative), but I view this as a less important reason. At any point, one should be able to go back to a given commit on master and ensure all tests pass.

Squashing should be avoided in situations where each commit in a given series is atomic, even if the commits deliver a feature in combination (unless, as alluded to above, some commits break the codebase in isolation). Incremental commits often represent the logical sequence of steps the author took as they developed the code. Without such a sequence, it is often very difficult to tell *why* a given change was made *among* others. so squashing must be used judiciously.