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…
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!
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.
Totally agree, if the developper goes in wrong product direction at the beginning and add 10 additional commits afterwards: team + 6 month actually don't care about it.
I certainly see no point in merging it in when it based on an ancient ancestor
If you want the CI to run, before the merge on the result it will produce on main branch ?
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!