wtf is squash-is-for-savages?

This repository isn't software, it's a long-form essay arguing for a specific approach to merging code in Git. The author, JP Bochi, makes the case that teams should use "merge commits" rather than "squash-merging" when integrating a branch of work back into the main codebase. Here's the core disagreement. When a developer finishes work on a feature branch and merges it into the main branch, they have choices about how to handle the commit history. "Squash-merging" collapses all the individual commits from that branch into a single commit, producing a clean, linear history on the main branch. The author argues this is "history destruction." The alternative, merge commits, preserves the branch's individual commits but wraps them in a merge commit that ties them together. The author prefers this because it keeps the full record of how the work evolved. The essay walks through several common arguments in favor of squash-merging and pushes back on each. For instance, people often say squash-merging is better because branches contain messy, throwaway commits (typos, "WIP" messages, debugging tweaks). The author's response: clean up your commits before merging, the same way you'd clean up your code. He argues that knowing squash will happen anyway fosters a culture of not caring about commit quality. He also pushes back on the idea that squash-merging produces a "perfectly linear history" that's some kind of golden ideal, branching is unavoidable in real-world development, and pretending otherwise is utopian. The practical recommendation is straightforward: use the "merge commit with semi-linear history" option in GitLab (or the equivalent in GitHub), which forces a rebase before merging and creates what the author calls "good merge bubbles." He's not against squashing individual commits when it makes sense, he's against a blanket policy that squashes every branch by default. This is aimed at engineering teams and tech leads deciding on their Git workflow. It's a opinion piece, not a tool, and it's written for people who already use Git and want to think carefully about how their team's merge strategy affects code history, debugging, and commit culture.