Version Control with Git

Pushing, Pulling, Branching, and Merging with git svn

Rebasing all the time is fine if you simply want to use Git as a glorified Subversion repository mirror. Even that by itself is a great step forward: you get to work offline; you get faster log, blame, and diff operations; and you don’t annoy your coworkers who are perfectly happy using Subversion. Nobody even has to know you’re using Git.

But what if you want to do a little more than that? Maybe one of your coworkers wants to collaborate with you on a new feature using Git. Or perhaps you want to work on a few topic branches at a time and wait on committing them back to Subversion until you’re sure they’re ready. Most of all, maybe you find Subversion’s merging features tedious and you want to use Git’s much more advanced capability.

If you use git svn rebase, you can’t really do any of those things. The good news is that if you avoid using rebase, git svn will let you do it all.

There’s only one catch: your fancy, nonlinear history won’t ever be in Subversion. Your Subversion-using coworkers will see the results of your hard work in the form of an occasional squashed merge commit (see Squash Merges), but they won’t be able to see exactly how you got there.

If that’s going to be a problem, you should probably skip the rest of this chapter. But if your coworkers don’t care—most developers don’t look at others’ histories anyway—or if you want to use it to prod your coworkers to try out Git, what’s described next is a much more powerful ...