Why I Prefer Regular Merge Commits Over Squash Commits

“Wow, that’s so cool!” I’ll always remember seeing my first squash commit. When I first joined a large engineering organization with more than 200 members, the squash commits were the first thing I noticed. To me, the consistent use of squash commits across the company screamed “professionalism” and “we know what we’re doing here!” It took me about a month to realize that I really, really didn’t like squash commits, and I started longing for good, old-fashioned merge commits. <h1>Comparing Squash vs. Merge Git Commits</h1> As a refresher, the difference between a “squash commit” and a “merge commit” is that a regular “merge” includes all of the Git commits in the history of the target branch, while “squash” flattens them to one commit. Confusingly, “squash” isn’t its own command. Instead, you can choose “squash and merge” or “squash and rebase” as an option when you’re running the <code>git merge</code> or <code>git rebase</code> commands, respectively. By default, a pull request (PR) will be a merge commit, so after the PR is merged then the entire history of the working branch will be merged in, plus an additional commit (“Merge pull request #21 from branch…”). On the other hand, you can set your repository to “squash and merge” by default, meaning merged PRs will result in only a single commit each, instead of bringing over all the commits from the working branch. <a href="https://betterprogramming.pub/why-i-prefer-regular-merge-commits-over-squash-commits-cadd22cff02c">Website</a>