With squash merge, Github will either: 1. Create a single commit and a merge commit that's empty because the single commit's parent is the current HEAD commit

With squash merge, Github will either: 1. Create a single commit and a merge commit that's empty because the single commit's parent is the current HEAD commit of the master branch 2. Create a single commit and a merge commit that has a diff because the single commit's parent isn't the HEAD commit of the master branch Scenario 1 essentially doubles the number of commits in the history, and the information in the merge commit message could easily be included in the squash commit message by amending it. Scenario 2 does the same thing, but could easily be changed to scenario 1 by rebasing on the HEAD commit of master before doing the squash merge. The fundamental problem with squash merging is that, depending on the scope of the PR change, you basically end up with a large commit that contains many changes that really ought to be separate individual commits. Those large commits are difficult to revert due to the sheer number of conflicts one will encounter when trying to revert them. On the other hand, well crafted individual commits can easily be reverted and are less likely to result in a conflict. Even if there are conflicts, they are limited in scope and can easily be dealt with since the commit itself doesn't really touch as many lines of code.