This sounds like horrible advice. Especially the part about git bisect: it is indeed an often situation, where both feature branch changes and master branch changes are correct by themselves, and only introduced the bug when combined. And in this situation, git bisect pointing to the merge commit as culprit is exactly what should happen, because incorrectly implemented merge, which didn&#x27;t take care of interface changes (for example), is exactly the reason for such a problem.<p>This exact situation is also the reason why I hate git rebase: it rewrites history and hides it&#x27;s real complexity under leaky abstraction. When I tried to use it, I found myself guessing a few months later: were these commits really how I (or a team member) wrote this code? Or may be these are actually rebased commits?<p>So, this statement:<p>&gt; having the history linear without any merge commits could immediately point out the commit that causes issues.<p>Is laughably incorrect. When you make your history linear, you can no longer pinpoint the commit that caused issue, because after doing rebase, <i>you destroyed it</i>. The original commit that caused the issue is no longer there. Or, it never was there: if the issue was introduced not by individual change set A or B, but by there combination, then the merge commit would the one that caused the issues. But since you did rebase instead, the <i>`git rebase` command was the &quot;commit&quot; that caused your issues</i>! But, of course, you won&#x27;t see it in git&#x27;s history.