If you have a nasty nasty difficult to find bug that emerged some time ago, and your history is littered with merge commits, git bisect is going to go badly. I

If you have a nasty nasty difficult to find bug that emerged some time ago, and your history is littered with merge commits, git bisect is going to go badly. If your history is linear, and your data model is compatible with itself across history for the bits you're interested in, and you can write a sane test case - auto or manual, then your troubleshooting is going to be O(n^x) simpler than the case where you've got merge commits, and save you many hours. Not something I have to do often (once a year or less really) but valuabable enough that it's important to me nonetheless. Rewriting history when things land in develop/master I think is a good thing. To use an analogy from the humanities, history is written by the winner. At work we're collaborating with the merge camp at the moment and it's very difficult to work out what they're doing from reading their history - some of it is their bad practices elsewhere, but the merge commits are confusing. I'd also be fine with no rebasing but any merges must be fast forward, so if you can't do that fix your problems prior to integration. Also I've used a few different approaches for a few different projects, and the rebase/squash merge approach is the one that in my experience makes things clearer and easier to understand. I'd be reluctant to return to other approaches (aside from enforcing fast forward merges in public branches). I believe that squash merges are a good compromise as so long as you don't mess with the reflog and keep the automated parts of the commit messages, then there is no lying about history.