This post is part of a series on Git and Subversion. To see all the related posts, screencasts and other resources, please click here.
This one explains some more of the physics of syncing repositories between Git and Subversion land. The big morale is that you can't really work with branches the way they were made in Git. History will have to be linear by the time you want to push back to Subversion, if you don't want to lose history. This basically requires every merge operation to be a rebase instead.
Theoretically, you could do branches between Git collaborators, but it's probably best to not stay so long out in Git before pushing changes back to Subversion, anyway, so the case for doing any useful branches are basically lost.
You can still do local branching for experimenting with some wild refactoring, or just for sorting different working sets of your code (I do this a lot, in fact). But as long as it's going back to Subversion, it'll have to be straightened up and rebased sooner or later.
This episode is a lot longer than the first ones, almost 15 minutes. I like to keep them shorter, but there was a lot of stuff to go through. I don't spend a huge amount preparing for the recording, and I'm not so interested in spending too much time editing it anyway, so there is some slack in there.
There's a lot of command line action in these videos, so I like going slow and keeping it simple so most viewers can follow what's going on. Do you think the pace is alright? I'd love to hear some more feedback in the comments (preferably here under the blog, not on YouTube).
You can find the first three episodes here.