Merge commits do so much harm, it's outrageous that anyone would think they're any good (save for git merge --no-ff a branch that has already been rebased onto

Merge commits do so much harm, it's outrageous that anyone would think they're any good (save for git merge --no-ff a branch that has already been rebased onto the branch it's being merged into). If I'm working along on a branch and someone commits something remotely, I can: git pull and get their changes as a merge commit or git rebase origin/master and get their changes below mine The big difference here is that if I have a conflict with their changes and I do a merge, I resolve those conflicts in the merge commit. This is terrible for a few reasons: * It means my commits are inherently broken. They're only made un-broken by the merge commit * When anyone else looks at my commit history, they have to look not only at the commits that I made but at the merge commit that resolved the conflicts from the prior commit, otherwise they're using a bad commit as a reference * When I do eventually merge my branch in, there will be a mess of commits from master splayed all throughout my commits, so that nobody can easily see what commits were actually mine without doing a git log origin/master..my_branch to see just what my branch is adding Now, if I decide to use rebase instead of merge, I resolve those conflicts at the point in which they would have occurred on my branch, thereby making my commits conflict-free. My history is also compact as it isn't spread over time with (possibly multiple) merge commits from master. If you happen to do merge commits you cannot easily rebase that branch without ripping out the merges first using something like git rebase --onto (http://pivotallabs.com/users/khicks/blog/articles/2118-git-rebase-onto http://pivotallabs.com/users/khicks/blog/articles/2118-git-r...). You can have git try to replay the merges at the point they occurred via git rebase -p (preserve merges), but that's dangerous and not useful territory to be in. The brunt of your argument seems to be that you'd prefer people to be constantly pushing to master features that are incomplete or otherwise don't work, all for the sake of having other people have your broken or incomplete features available for them to start writing code against. This is madness. You have to manage that mess with feature flags or other song-and-dance nonsense that you could avoid entirely by using rebase instead of merge and only putting your stuff on top of master (either via rebasing your commits onto master as the OP notes or by --no-ff merging the branch, as I noted earlier). In addition to that, you can no longer easily even tell what a feature was. Maybe you use commit messages that have a story/card/bug ID that you can use to track, but man, I'd hate to rely on that. I've used the rebase strategy for multiple years now with teams of 20-60 people, distributed across countries with great success. I have yet to hear a reasonable argument for merging other than "but, but.. you can't silo your work!" The hell I can't. I'm going to work on the feature branch until, at minimum, the feature is passed by QA as being feature-complete. Until the point of me putting my work onto master I have absolute control over squashing/rearranging commits, messages, deleting commits, and doing whatever the hell else I want to do to make sure my commits are all green (passing all tests), conflict-free, and sensible. Hell, I've even done talks on my rebase-based Git workflow. Until that point, my commits aren't useful to anyone because the work is by definition incomplete. I care more about a clean, readable, green commit history than someone's idea that having all code pushed to master as soon as it's written is somehow better.