&gt; Au contraire, rebase can break bisect by creating commits that were never actually tested or compiled. And if your bisection algorithm cannot handle merges, then that&#x27;s a problem with a bad bisection algorithm.<p>This is only true if you allow commits that haven&#x27;t individually passed your CI suite to be pushed. That&#x27;s insane.<p>&gt; Nor does it make history more readable; it makes history more readable in the same sense that inlining all procedures makes a program more readable (i.e. not really).<p>Working at an organization (Google) that for the most part doesn&#x27;t use branches and where other merges are impossible (every file must have previously been resolved against whatever is at HEAD prior to submitting), I respectfully disagree[0]. A linear history of individually reviewed and validated changes is MUCH easier to deal with than the regularly branched&#x2F;merged history of my previous gig (which did use git, along with pre-push change review for each change).<p>&gt; Merge commits are an abstraction mechanism. You can view a branch&#x27;s history as a purely linear history (git log --first-parent) of normal and merge commits, where merge commits represent the merged branches (and where the commit message should summarize the branch changes properly). You can then unfold merge commits and view the branches they represent in such a quasi-linear fashion, too. Repeat as needed.<p>They&#x27;re a leaky abstraction, though. Unless you mutate published history (which I do think is insane) it&#x27;s inevitable that your nice bundle of merged changes will one day be incomplete: additional changes to make the bundle actually function as intended will be required. These will end up detached from it as some other commit series on HEAD or merged into HEAD. I find it far easier to tie together a series of changes via things like issue tags in the commit than expecting a merge commit to properly bundle things up.<p>[0]: Mind you, Google also for the most part does not use git -- we do our own thing, and with that history is necessarily linear, but I&#x27;ve found I really do prefer it that way. See: <a href="http:&#x2F;&#x2F;www.wired.com&#x2F;2015&#x2F;09&#x2F;google-2-billion-lines-codeand-one-place&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.wired.com&#x2F;2015&#x2F;09&#x2F;google-2-billion-lines-codeand-...</a>