<i>The merits of merge commits have already been proven</i><p>That is an opinion, many people clearly disagree with it.<p><i>Using rebases is basically rewriting history</i><p>Yes. Why is that a bad thing?<p><i>If you want all work done precisely as happened in real life you should always use merge commits</i><p>Why is that important at all?<p><i>Saved my ass a bunch of times.</i><p>So has reflog.<p>I personally don&#x27;t find any compelling rationale for why I need the git history to reflect what actually happened in time. That seems entirely incidental. Who cares if you made 10 commits on your branch or 2 or 1? Who cares if you actually wrote one part of a feature before another?<p>The purpose of having history is another way of communicating design intent to other people that look at the history, no more, no less. Therefore why shouldn&#x27;t it be editable? It&#x27;s like arguing that a typewriter and whiteout produced better books than a word processor.<p>I also use rebase to extract portions of the feature that are merge able before the rest. Or you can pull out sections of a branch when you are happy with them and branch off a few experiments on top of that solid base, finally merging in the one that works out best. Not employing those techniques is akin to not knowing how to refactor code.