alt Hacker NewsThe clean linear history thing is something I never really got, despite using git for 12 years now. I worked with some smart developers whose rule was "rebase if you want, but if too complicated, just merge", and it didn't hurt the delivery or maintainability of the code they wrote.
Replies
It really depends on how often you use git bisect and blame. This varies greatly across projects.
That said, if/when stacked PRs become a first-class citizen in GitHub, more projects will see the benefit of this approach (though they'll probably mostly get there through squash-merges).
Agreed.
For a complicated long running feature branch I can see it. Instead of repeatedly merging the root in during development it can be cleaner. Tools aren’t always good at figuring out in a PR what was written and what was caused by those merges from root. And history looks better at the end.
For a short branch that can merge cleanly or perhaps very close to it, I’d kind of rather have the ‘true’ history. I don’t think it’s worth it.
I’ve never understood the “everything must be rebased before every merge” desire.
Yes - whenever I'm in a team and I hear someone who insists on a linear history, I always wonder why they have trouble with merge when lots of folks like me have no problem with it.
Finally, in one team, I more or less forced a senior engineer use merge (or rather, I was in control of the project and did not force other developers to use rebase). After a year, he admitted that he no longer really saw a benefit in rebase and switched to just using merges in his own projects. He also noticed fewer merge conflicts this way.