I've been thinking about the Git development workflow lately and the trend towards linear histories, where every pull request is fast-forwarded and based on a branch rebased onto the main branch. It seems like a clean and streamlined approach, but are there still valid use cases for allowing non-linear Git histories?
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…<p>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.<p>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.<p>If some people want to keep unsquashed, unrebased branches for archival purposes? Fine! But rebase before merging to main/master!