Or, why I dislike squash merges.

Tralfamadorians have the ability to experience reality in four dimensions; meaning, roughly, that they have total access to past, present, and future; they are able to perceive any point in time at will.

Kurt Vonnegut

The code usually tells you the what and sometimes the how. It doesn’t often delve into the why.

That’s where the git commit messages come in. Squash merges tend to at worst eradicate them and at best jumble them into one single large commit message comprised of every squashed message. That makes it a lot harder to get to the meaning of what you were trying to find out, that led you to open a line of code’s associated git log in the first place.

When you have a version controlled project to hand, you are a Tralfamadorian. You have access to the project’s fourth dimension. Every state it’s been in that was worthy of a discrete commit. The more discrete commits there are, the more information you have available to you.

In addition, git bisect is far more useful given a larger number of smaller scale commits to work with. That, coupled with a good commit message, will assist greatly in handling the issue that led you to use bisect in the first place. To avoid introducing a regression, you need to fully understand the change, its context, what it was trying to achieve.

Of course, squash merges have their place, because nothing is absolute and almost everything is “it depends”. If a PR is full of “wip” commits or “close of play” commits, for instance, then yes you’re going to make it more coherent by removing those. It’s the absolutist “squash everything” that can nuke important details and this is more of a problem the larger or longer lasting a feature branch has been.

We should be considered and deliberate in the information we present into our git history, preserving and enhancing the ability of future custodians to understand our changes.