Tim Reynolds

Software & Startups

To squash merge or not to squash merge

For a long time I've worked on commercial software, therefore become an advocate of squashing commits to master. Why? Mostly simplicity.

Say I'm deploying master to production, trunk based deployment methodology, squashing commits gives me clarity. Enabling me at a glance to understand how the codebase evolved, which commit could be reverted to remove that nasty bug and free of the baggage of every "fixed", "remove .txt file" and "updated test" commit it took me to get to a functioning version of the feature I was working on.

However, with open source it's different, most people are no longer paid for their contribution so in return it's only fair their contribution is accredited correctly.

Pull Request contributions historically have been poorly represented in GitHub with the account who merged the squash PR taking all the glory. In fairness, it's been improved more recently with accrediting the commit author and merge author, but pull requests with more than a single committer get attributed to the last commit author when squashed.

So be considerate when you merge, learn how commits with multiple authors work and maybe rethink only allowing squash merge in your open source projects.


more words@timjreynolds |  linkedin |  github