Merge gives an accurate view of the history but tends to be “cluttered” with multiple lines and merge commits. Rebase cleans that up and gives you a simple A->B->C view.
Personally I prefer merge because when I’m tracking down a bug and narrow it down to a specific commit, I get to see what change was made in what context. With rebase commits that change is in there, but it’s out of context and cluttered up with zillions of other changes from the inherent merges and squashes that are included in that commit, making it harder to see what was changed and why. The same cluttered history is still in there but it’s included in the commits instead of existing separately outside the commits.
I honestly can’t see the point of a rebased A->B->C history because (a) it’s inaccurate and (b) it makes debugging harder. Maybe I’m missing some major benefit? I’m willing to learn.
I feel the opposite, but for similar logic? Merge is the one that is cluttered up with other merges.
With rebase you get A->B->C for the main branch, and D->E->F for the patch branch, and when submitting to main you get a nice A->B->C->D->E->F and you can find your faulty commit in the D->E->F section.
For merge you end up with this nonsense of mixed commits and merge commits like
A->D->B->B’->E->F->C->C’ where the ones with the apostrophe are merge commits. And worse, in a git lot there is no clear “D E F” so you don’t actually know if A, D or B came from the feature branch, you just know a branch was merged at commit B’. You’d have to try to demangle it by looking at authors and dates.
The final code ought to look the same, but now if you’re debugging you can’t separate the feature patch from the main path code to see which part was at fault. I always rebase because it’s equivalent to checking out the latest changes and re-branching so I’m never behind and the patch is always a unique set of commits.
I would advocate for using each tool, where it makes sense, to achieve a more intelligible graph. This is what I’ve been moving towards on my personal projects (am solo). I imagine with any moderately complex group project it becomes very difficult to keep things neat.
In order of expected usage frequency:
Rebase: everything that’s not 2 or 3.
keep main and feature lines clean.
Merge: ideally, merge should only be used to bring
feature branches into main at stable sequence points.
Squash: only use squash to remove history that truly
is useless. (creating a bug on a feature branch and
then solving it two commits later prior to merge).
History should be viewable from log --all --decorate --oneline --graph; not buried in squash commits.
Folks should make sure the final series of commits in pull requests have atomic changes and that each individual commit works and builds successfully alone. Things like fixup commits with auto squash rebase. THIS WAY you can still narrow it down to one commit regardless of the approach.
Merge gives an accurate view of the history but tends to be “cluttered” with multiple lines and merge commits. Rebase cleans that up and gives you a simple A->B->C view.
Personally I prefer merge because when I’m tracking down a bug and narrow it down to a specific commit, I get to see what change was made in what context. With rebase commits that change is in there, but it’s out of context and cluttered up with zillions of other changes from the inherent merges and squashes that are included in that commit, making it harder to see what was changed and why. The same cluttered history is still in there but it’s included in the commits instead of existing separately outside the commits.
I honestly can’t see the point of a rebased A->B->C history because (a) it’s inaccurate and (b) it makes debugging harder. Maybe I’m missing some major benefit? I’m willing to learn.
I feel the opposite, but for similar logic? Merge is the one that is cluttered up with other merges.
With rebase you get A->B->C for the main branch, and D->E->F for the patch branch, and when submitting to main you get a nice A->B->C->D->E->F and you can find your faulty commit in the D->E->F section.
For merge you end up with this nonsense of mixed commits and merge commits like A->D->B->B’->E->F->C->C’ where the ones with the apostrophe are merge commits. And worse, in a git lot there is no clear “D E F” so you don’t actually know if A, D or B came from the feature branch, you just know a branch was merged at commit B’. You’d have to try to demangle it by looking at authors and dates.
The final code ought to look the same, but now if you’re debugging you can’t separate the feature patch from the main path code to see which part was at fault. I always rebase because it’s equivalent to checking out the latest changes and re-branching so I’m never behind and the patch is always a unique set of commits.
I would advocate for using each tool, where it makes sense, to achieve a more intelligible graph. This is what I’ve been moving towards on my personal projects (am solo). I imagine with any moderately complex group project it becomes very difficult to keep things neat.
In order of expected usage frequency:
History should be viewable from log --all --decorate --oneline --graph; not buried in squash commits.
Folks should make sure the final series of commits in pull requests have atomic changes and that each individual commit works and builds successfully alone. Things like fixup commits with auto squash rebase. THIS WAY you can still narrow it down to one commit regardless of the approach.