> Merges are hard to follow and may include conflict resolutions which are hard to show (if they show up at all). My experience is much the opposite. You can f

> Merges are hard to follow and may include conflict resolutions which are hard to show (if they show up at all). My experience is much the opposite. You can follow all the merge parents and three(+)-way diff them with the final merge result to see just the conflict resolutions in a merge. On the other side, tracking down accidental bad conflict resolutions (which result in regressions) in rebased branches is nearly impossible because there's no single commit that just represents the conflict resolutions; depending on the developer doing the rebases they might be smeared across every commit in the entire branch. It gets hard to tell what changes were deliberate and which were conflict resolutions that the developer handled in some way maybe not so deliberately. There are some massive failure cases for regressions I've seen including having to get deep into the woods of git's rerere cache infrastructure and forcing developers to clear that cache so that they stop reintroducing the same kinds of hard to track down regressions in their rebases. (I am grateful that this worst case behavior is rare enough not everyone feels it; I've seen it just enough I prefer that junior developers rarely to never rebase because merge commits preserve more of the process and don't hide the mistakes under the rug.) That said, I definitely agree that short-lived branches and code getting integrated as fast as possible so that conflict resolution is done early and often and as visibly as possible is a good idea.