The difference between `svn commit` and the various forms of `git add` or rebasing is that the developer can test the commits (or visually inspect them) before

The difference between `svn commit` and the various forms of `git add` or rebasing is that the developer can test the commits (or visually inspect them) before pushing. In fact, the argument that `git add -p` produces a commit that didn't exist on disk is exactly the same as the argument that developers can commit code that they never actually built & tested. Which is to say, the important point isn't that the commit tree existed in isolation on the developer's disk, but rather that the developer did any testing necessary to verify that the commit is good. And the reason why `svn commit` is bad in this regard is because it creates the never-before-seen result on the server. > The conflict is often unavoidable If the conflict is unavoidable, then you're going to get a conflict regardless of how you go about it (rebase vs merge vs `svn update`). The difference is with `svn update` you can't abort the whole process and start over if you need to, because you've already permanently lost the previous state of your work tree. Whereas with `git rebase` and `git merge`, you can abort and you'll get the exact state you had prior to the command.