For code reviews that take days/weeks, it is useful to not rebase the branch to main/master on every update… But I certainly see no point in merging it in when it based on an ancient ancestor…
I’ve heard some like the non-fast-forward approach because it preserves the historical state of the tree when a developer was writing something… Often the same people who don’t squash commits and merge 100 commit branches where 99 are a complete mess.
But to me, what matters is the actual change to main/master at the time the thing is merged — that is what affects the team.
If some people want to keep unsquashed, unrebased branches for archival purposes? Fine! But rebase before merging to main/master!
I’ve heard some like the non-fast-forward approach because it preserves the historical state of the tree when a developer was writing something… Often the same people who don’t squash commits and merge 100 commit branches where 99 are a complete mess.
But to me, what matters is the actual change to main/master at the time the thing is merged — that is what affects the team.
If some people want to keep unsquashed, unrebased branches for archival purposes? Fine! But rebase before merging to main/master!