Write about "Why squash commits make sense for history and collaboration"

[Tehnix]

Description

When working in teams on a project the history of the project starts to become more and more important for understanding changes and context over time. Working in a standard Pull Request based flow, we are faced with a couple of options for how we want our changes to be incorporated into the main branch again. A lot has already been said about the pros and cons of merge commits, squashing, or rebasing. Most of these approach the decision with a technical mindset, but there's a nuance that I have not really seen before: what's best for collaboration?

Let's take a look at a couple of popular open-source projects to see the impact of this choice:

• Squash: aws-cdk, typescript
• Merge commit:

To do:

• Go through each project and take a look at the history breaking down what changed in the repository
• After this, go into my view on PRs as a single entity that should not be broken up
• Explain why breaking up a PR can be bad, e.g. CI checks failing in the middle, early commits no longer making sense after review and changes, etc

Bonus:

• Rollups: rust