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.
Feedback?
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.
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.
Feedback?
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.
Thanks for your effort, it's hugely useful - you saved lots of my typing I'd have done to inform our colleagues.
ReplyDeleteA note about this particular post - I feel this a bit wrong:
"This basically requires every merge operation to be a rebase instead ... you could do branches between Git collaborators, but ... the case for doing any useful branches are basically lost."
In my experience, you can branch/merge away, share with collaborators - assuming you know the rules of the game.
The only thing: before dcommit "it'll have to be straightened up" - as you rightly said.. but again that's the last stage, and it doesn't even have to be a rebase (merge --squash comes to mind).
Hi Gin, thanks for your comment! I'm glad to hear these posts can be of some benefit out there :)
ReplyDeleteYou're absolutely right about the merging. You can save all the "ironing" till last, and squash works well for this purpose, although a little rebase-foo might come in handy (like with the --onto argument).