Menu
Some people like git merge --squash due to the reason as follows:
Squashing to a single commit gives you an opportunity to clean up messy WIP commits and provide a good rationale for the changes your are merging.
https://coderwall.com/p/qkrmjq/git-merge-squash
However, I think there is some downside which exceeds the merit of producing a clean history.
git merge --squash produces a non-merge commit. Therefore, Git will not recognize that the commit you are merging from as the merge base. This leads to unwanted merge result when 1) change A to B on branch X, 2) git merge --squash from branch X to branch Y, and 3) change B to A (revert) on branch X, and 4) merge X into Y.
After step 4, on branch Y, the change from A to B is NOT reverted. Here, this is 3-way merge, so a diff from branch X to merge base and another diff from branch Y to merge base are compared. The former one includes no change, and the latter ones include change from A to B, so the merge result include the change from A to B.
Commit author is overridden, which discards the contribution. git merge --squash produces a new commit with the name who did git merge --squash. Of course, the commit content is from the original commits. This sounds like stealing the contribution. This became a problem in https://github.com/Microsoft/winfile/pull/42#issuecomment-380681627
What are the proper use cases of git merge --squash?
872
To "squash" in Git means to combine multiple commits into one. You can do this at any point in time (by using Git's "Interactive Rebase" feature), though it is most often done when merging branches. Please note that there is no such thing as a stand-alone git squash command.
Squash merging is a merge option that allows you to condense the Git history of topic branches when you complete a pull request. Instead of each commit on the topic branch being added to the history of the default branch, a squash merge adds all the file changes to a single new commit on the default branch.
Squash merges, as it's proponents argue, are more valuable than merge commits because entire new features or bug fixes can be compressed into a single commit and therefore easier to code review and read at some point in the future.
You should consider using squash if your team prefers a linear project history. This means that the history held by your main branch should not contain merges. A squash merge makes it possible to keep changes condensed to a single commit, supporting this strategy nicely.
What are the proper use cases of
git merge --squash?
If the project has a policy of not allowing merge commits on its master branch anyway, then the fact a non-merge commit is created is not a problem (it's exactly what you'd want anyway).
If you don't plan to use the Y branch again after the merge (e.g. because Y is a short-lived feature branch and the feature is merged to X now) then it's irrelevant that a future merge from Y has the "wrong" merge-base. You're not going to do any future merges from Y anyway.
Or if you rebase branch Y on X after the merge, then future merges from Y will have the right merge-base.
If all the commits on the branch are by the same author, then the second problem doesn't exist either.
So it might not be useful in all cases, but there definitely are cases where it's perfectly fine to use. The most obvious one is for a local branch where WIP commits are made, before pushing them somewhere other devs can see. All the messy WIP commits on branch Y are by the same author, and nobody else is ever going to see branch Y so it's fine to rebase it on X after the merge, or to just throw Y away completely if even you aren't interested in the WIP history.
66
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
