Two Years of Squash Merge (2019)
I will always fight tooth and nail against squash merge.<p>Squash merge has the major disadvantage of getting rid of valuable meaningful git history.<p>Squash merge is not the proper solution for keeping your git history clean, it is a hack using the side effect of squash.<p>Keeping your git history clean is a matter of policy, best-practices and education:<p>Developers should be required to submit _clean_ PRs, that is, PR&#x27;s whose git history has been organized and refactored in such a way that it removed &quot;clean up commits&quot;, &quot;typo fix&quot;, etc.<p>When you squash merge a feature branch that has thousands of lines of code, and 6 months later you have a bug introduced by this feature branch, it becomes extremely hard to find which line introduced the bug.<p>On the other hand, if you kept the history, and if this history was clean from the get go, it becomes easy to read the commits one-by-one and understand the issue.<p>Don&#x27;t use squash+merge.<p>edit: I see numerous comment saying, in essence, &quot;squash+merge&quot; is what gets rid of the dirty history. No, developers must learn the existence of `git rebase --interactive`, which is the command to use to clean your git history[0]. &quot;squash&quot; is one possible action, among others, that helps cleaning the history.<p>[0]: <a href="https:&#x2F;&#x2F;git-scm.com&#x2F;book&#x2F;en&#x2F;v2&#x2F;Git-Tools-Rewriting-History" rel="nofollow">https:&#x2F;&#x2F;git-scm.com&#x2F;book&#x2F;en&#x2F;v2&#x2F;Git-Tools-Rewriting-History</a>