To squash or not to squash
Squashing is the act of combining multiple commits into one, with the intent of simplifying commit history. It can be done manually through Merge, or automatically when merging a pull request.
Some teams swear by the squash and merge option, mostly because it keeps history on the main branch clean and linear. But at what cost?
The good
If your team is creating small pull requests and adopts a review style based on file changes (as opposed to commit-by-commit), then squashing works well. This is because the commit history of the pull request branch isn’t providing any additional value to the final diff:
In this case, squashing drastically reduces “noise” on the main branch:
The example above assumes a linear timeline: one pull request is created (or rebased) after another is merged. This is rarely true, so the commit history on the main branch is often a lot more messy without squashing.
The bad
In reality, most teams haven't reached the level of maturity needed to consistently create small pull requests. And those who have will likely move on to trunk-based development as a natural next step, rendering pull requests unnecessary.
So if your pull requests are still on the large side, squashing will (by design) result in large commits on the main branch. This makes troubleshooting (e.g. pinpointing a change that introduced a bug) a lot more difficult, and Bisect a lot less useful.
Large pull requests are also trickier to review by file changes, so you can improve the reviewer experience by creating cohesive commits. But if your pull request is reviewed commit-by-commit, then it shouldn't be squashed. Because those commits clearly have value, and thus should be preserved.
Having it both ways
Squashing doesn't have to be all or nothing. Your team can default to a preferred mode but should evaluate whether the alternative is better on a case-by-case basis. If your team is merge by default, it's okay to squash single-commit pull requests. If your team is squash by default, it's okay to merge complex pull requests.
Ultimately, team policies exist to help people make good decisions. If these policies are too restrictive, it might be time to rethink them.