Skip to content

Instantly share code, notes, and snippets.

Created September 23, 2010 22:05
  • Star 2 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
Star You must be signed in to star a gist
What would you like to do?

#How I use Git-SVN

I've just realised that all my git and git-svn posts are on the Atlassian Extranet and thus lost to me. So here's a quick re-write of one of them, for Mike Cravey. Please feel free to fork and add your own recommendations or suggestions:

I've never used TortoiseGit and I barely remember Windows CLI (do they still call it DOS?) commands, but you know OSX shizzlit so I'll just write it as I know it and you can translate ;)


I like to clone the whole repo, branches, tags and all. If you're in a rush, do this anyway, then check out just the branch you need right now somewhere else. I find it saves heaps of time and hassle later if you're set up right.

git svn clone -T trunk -b branches -t tags

Make sure you're checking out the SVN root, not /trunk

Folks always tell me you can use -s or --stdlayout to replace the flags at the end there, but I have never ever had it work for me and you can waste an awful lot of time checking out a repo only to find it's only got trunk and have to start again.

Standard practice

From master I create a working branch (usually for the issue number I'm working)

(master) $ git co -b work-52

do some work...

(work-52) $ git ci -a -m "awesome commit message"

(work-52) $ git co master

Grab the latest from SVN: (master) $ git svn rebase

Rebase my work into master: (master) $ git rebase work-52

This keeps my history neat, with only commits for work (as much as possible) - otherwise, SVN takes the merge as the first line of the commit message and that's crap for reading your history in SVN browsing tools etc later. (and must REALLY suck for your colleagues who are still on SVN)

Push to SVN: (master) $ git svn dcommit

Delete the working branch (even if we're going straight back) (master) $ git br -D work-52 (master) $ git co -b work-52

The deletion means not having to rebase back. It also means you don't end up with a lot of one-shot local branches hanging around.

That's the simplest, and I've found best, way to work with git-svn. Don't ever commit in master. Things can get messy really quick if someone has committed conflicting changes.

When shiz gets messy

If it's a particularly fast-moving project (or phase) and you pull down likely conflicting changes. I like to rebase master back into the working branch. Or better yet create a test branch from it for the rebase. So it goes something like:

(master) $ git co -b work-52
do some work...
(work-52) $ git ci -a -m "awesome commit message"
(work-52) $ git co master
(master) $ git svn rebase

Huge chunk of stuff that's bound to conflict...

(master) $ git co work-52
(work-52) $ git co -b test
(test) $ git rebase master

fix conflicts and generally work out how bad things are...

(master) $ git svn rebase 
just in case!

(master) $ git rebase test
(master) $ git svn dcommit
(master) $ git br -D work-52
(master) $ git br -D test

There are doubtless better ways to do these things. I'd love to hear them.

Oh and the problem I had the last couple of days:

Multiple SVN branches

I've never normally had a problem with this (and our repos at Atlassian had lots of branches) but this week it drove me nuts.

How handling multiple SVN branches from a local git clone should work

Make sure you've got all the goods: (master) $ git svn fetch

Check your remotes: (master) $ git br -r

Checkout the one you want: (master) $ git co remotes/cool-new-shiz

bunch of warning notes about how you're not on a local branch etc etc...

Checkout your remote into a local branch: (no branch) $ git co -b new-shiz

Note: don't use the same name for the local as the remote cause that's ambiguous and you wouldn't like git-svn when it's ambiguous.

From now on, running 'git svn rebase' in new-shiz will rebase from the cool-new-shiz branch and dcommits with commit to that SVN branch

The problem

After one dcommit to the correct branch, it'd revert to pointing to trunk. Major fuck up.

I finally solved it by editing my .git/config file. The 'svn-remote' was referring to 'blahblahlbah/trunk' when it should have been 'blahblahlbah/*'

I'm now late for work.


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment