In my opinion if one could choose between a well executed and instant rebase versus a well executed and instant merge, one would be a fool not to choose a rebas

In my opinion if one could choose between a well executed and instant rebase versus a well executed and instant merge, one would be a fool not to choose a rebase every single time. In practice too, I also almost always choose rebases, BUT there are a few caveats here that are worth making… As a general rule rebases for more than a small number of commits in cases where conflicts are non trivial can take significantly more time and patience for the developer performing it. Instead of fixing the conflicts in one swoop, you have to sometimes resolve conflicts repeatedly in the same areas of code. If the conflicts are extensive this can be a very unpleasant experience even for experienced developers. For less experienced or less skilled developers each of these conflicts poses an opportunity to mess up. Since there are more of them when rebasing, there are also more opportunities to mess up. If the developer is in a rush or is simply impatient, I would also expect them to mess up more in a rebase than a merge. Yes, ideally we wouldn’t have massive branches that need to be rebased with many conflicts, but in practice if you are working on a codebase where a lot is happening frequently by lots of people in the same parts of the code or code is moving around, there are often no really good alternatives. While perhaps more changes can be made incrementally than people often admit (especially if you include feature flags and the like to allow for transitions — though those can come with their own pitfalls), in practicality, not everything can in practice be done without having longer branches (and not having unreasonably large changes in a commit). Sometimes large changes just need to be brought in together. Slow reviews or at least slow code reviews at the same level of effectiveness in the review can pose problems as well. If you want it properly reviewed in the safest possible way you really want no new code in the branch being merged to after the review begins — allowing a clean fast forward merge from the rebased branch, but that can be impractical in some codebases with a lot of activity. Merges can still be messed up and until recently it was quite hard to even see the merge diff to debug a bad merge, but there are admittedly fewer steps where you can mess up. All that said, I’m still a huge advocate of rebasing, but I get it that not everyone is up to the task. Sadly most developers have tons of awful, broken, and incoherent commits on their own branches that they never clean up. Until you can convince them to at least do fixups and cleanup the commit histories on their on branches with rebasing, arguing for rebasing over merges towards trunks is pointless. It requires more from the developer upfront. If your developers are good it will require much less from a maintenance perspective but the reality is that having a team of capable developers who are willing to do the work is not something one can take for granted in most places.