Is there still a need for non-linear Git histories in product development?
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!
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. 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 you want the CI to run, before the merge on the result it will produce on main branch ? I certainly see no point in merging it in when it based on an ancient ancestor