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.
At least a squashed merge I can drive all the chances with git blame, instead of focusing out what “format” that touched the whitespace on 3 lines is masking.
Downside: you can only have 1 single person be blamed for the squash. If multiple devs worked across multiple commits, you have to squash it down and pick just 1 person who’s name shows up for git blame, which can actually be a pain.
Ive already had cases where 2-3 months later I start getting pinged about changes to files I have never touched, only to realize my name is on it because I approved and triggered the final PR squash merge so like 4 devs worth of commits have my name on them, and I have zero clue which dev did which change or why, so it’s all squashed together.
It’s not even about bad code for “blaming”, but we have changes where the question is “why did we do this? Was it for an important reason?” and I have to go “I dont fuckin know, I know my name is on it but it was one of who actually did it and we have now entirely lost the git history on who actually did it so you’ll have to ask everyone and hopefully someone remembers why it happened…”
No. Thanks. Git rebase interactive is the only way to go, maintains git history and keeps everything clean, and its not even that hard to use if you use a sane IDE like lazygit or git extensions.
I’ve tended to rebase before anything else. If I feel unsure about the massive interactive rebase fuckery I’m about to embark on, I just make another branch where I start. Then undoing it’s fairly trivial.
And what this graphic fails to discuss is that all these methods should be done BEFORE pushing. Once pushed, then the hashes are set and if you do any squashing, fixuping, etc, then you are rewriting hashes (and history) — and possibly orphaning other developers local copy.
wait what
could this be why I’ve failed to understand this topic on several occasions? I don’t remember anything about push timing.
before you push what specifically?
And what if you accidentally push too soon?
The moment you push your changes to origin, other developers can then pull them. If you intend to squash or fixup commits, then you should do so after committing to your local git, but before you push to origin.
Once you push to origin, the commit hashes from your local branch become what origin has, and then those commit hashes are now possibly on another developer computer after they pull.
If you do a squash or a fixup, the existing commits are effectively rewritten into a new commit with a new hash so the developers who happened to pull what you previously pushed now have their HEAD pointing to a hash that no longer exists — thus orphaning.
Just use merge with informative PR titles, descriptions and linked work items. Reviewing history is then trivial and it has none of the pitfalls for less experienced devs.
![[Julia Evans] Combining Branches(programming.dev)](https://programming.dev/pictrs/image/0fe7c7bd-b762-453f-bac7-ed2e34d44ba0.png){kind=link}