This is the nightmare scenario. You are working with a coder who overwrites your changes in subversion. You’ve told this coder once, twice, three times, “Hey, please don’t do that. Hey, let’s talk about your changes before you commit them.”<\/p>\n
But this coder for some reason thinks that he or she is the gift of the gods when it comes to coding, and continues to overwrite your changes.<\/p>\n
This is where git comes in. If I had learned about this feature of git and the idea of accepting or rejecting changes in git sooner, I would have avoided the whole nightmare of re-comitting code and lengthy merge debates.<\/p>\n
Most projects you work won’t involve the worst case above. Most of the time, there will be a great developing rule that says never commit bugs into subversion. But whenever you have to re-factor code and commit each line, branching and then later merging can be an issue in subversion, and it’s slow too.<\/p>\n
On a project that I’m working on now the client wants only good code in svn which is great, and so I’m using git with svn. I got this idea thanks to Jakob Heuser<\/a>. Thanks, Jakob!!!!<\/p>\n