Merge. One of the values of a VCS is to preserve history in detail, and merge is the only method that does that. Also, it’s easy to foul a remote branch with the other methods if someone has already pushed changes to branch 1.
Shared branches should always only move forward. Most Git-* systems support stuff like protected branches.
I personally like tidying up your own feature branch with rebasing and then merging it into main (preferably using only FF merges). However this is not scalable for some larger projects, and for example monorepos also make this hard to accomplish. In those cases the solution ends up being squash+merge.
The extra information about the squashed commits is usually persisted to these systems (GitHub PRs, GitLab MRs, etc) so you don’t really lose much, I guess. Although I do prefer keeping it all in plain git.
I feel it’s a balance. Each operation has a purpose.
Rebasing makes sense when you are working in a feature branch together with other people so you rebase your own commits to keep the feature branch lean before you finally merge it into the main branch, instead of polluting the history with a hard to follow mess of sub branches for each person. Or when you yourself ended up needing to rewrite (or squash) some commits to clean up / reorganize related changes for the same feature. Or when you already committed something locally without realizing you were not on sync with the latest version of a remote branch you are working on and you don’t wanna have it as a 1-single-commit branch that has to be merged.
Squashing with git merge--squash is also very situational… ideally you wouldn’t need it if your commits are not messy/tiny/redundant enough that combining them together makes it better.
![[Julia Evans] Combining Branches](https://programming.dev/pictrs/image/0fe7c7bd-b762-453f-bac7-ed2e34d44ba0.png){kind=link}
Merge. One of the values of a VCS is to preserve history in detail, and merge is the only method that does that. Also, it’s easy to foul a remote branch with the other methods if someone has already pushed changes to branch 1.
Shared branches should always only move forward. Most Git-* systems support stuff like protected branches.
I personally like tidying up your own feature branch with rebasing and then merging it into main (preferably using only FF merges). However this is not scalable for some larger projects, and for example monorepos also make this hard to accomplish. In those cases the solution ends up being squash+merge.
The extra information about the squashed commits is usually persisted to these systems (GitHub PRs, GitLab MRs, etc) so you don’t really lose much, I guess. Although I do prefer keeping it all in plain git.
I feel it’s a balance. Each operation has a purpose.
Rebasing makes sense when you are working in a feature branch together with other people so you rebase your own commits to keep the feature branch lean before you finally merge it into the main branch, instead of polluting the history with a hard to follow mess of sub branches for each person. Or when you yourself ended up needing to rewrite (or squash) some commits to clean up / reorganize related changes for the same feature. Or when you already committed something locally without realizing you were not on sync with the latest version of a remote branch you are working on and you don’t wanna have it as a 1-single-commit branch that has to be merged.
Squashing with
git merge --squashis also very situational… ideally you wouldn’t need it if your commits are not messy/tiny/redundant enough that combining them together makes it better.