If you are familiar with git and have used it, you already know the power you get with it. If you are using SVN, you should take git for a spin and see how it can change the way you work.

Good news is you can use git on a SVN repository without any hacks. This post should help you get up and running with git-svn in no time.

This post assumes that you are already familiar with git. This post covers how to use git svn. If you are new to git you can get a crash course here.

Overview
If you do not have git installed on your system, you can download it from here http://git-scm.com/downloads
Git installation comes with “git svn”. This will allow you to clone a SVN repository and provide a git interface over it.

Cloning
You can clone from a SVN repo using the git svn clone command.

$ git svn clone svn://internal-repo/Project Project -s

-s = If your SVN repo follows standard naming convention where main source is in “trunk”, branches are created in “branches”.

You can also manually configure a git repo pointing to a non-standard setup by telling git svn about the specific location as such:

$ git svn clone svn://internal-repo/Project Project --trunk=trunk --branches=maintenance/* --prefix=git-svn/

Here we are telling git svn that trunk is the “trunk” directory, maintenance is the “branches” directory etc.

“git svn clone” starts pulling down code right away, which in most cases would work just fine. But, if you are working on a large repository it can take a few hours to fetch the code from trunk and all the branches.

If you do not want to fetch the entire code and its branches, you can set-up selective branches only.

Instead of git svn clone, let’s use git svn init.

$ git svn init svn://internal-repo/Project Project --trunk=trunk --branches=maintenance/* --prefix=git-svn/

When you do git svn init, it only creates the git configuration files and does not fetch the code right away.
After this code is run, git will create the “Project” directory in which there will be a “.git” directory.
Lets open the config file that is in the .git folder. This will help you understand the inner working of git svn.

[core]
	repositoryformatversion = 0
	filemode = true
	bare = false
	logallrefupdates = true
	ignorecase = true
	precomposeunicode = false
[svn-remote "svn"]
	url = https://internal-repo/Project
	fetch = trunk:refs/remotes/git-svn/trunk
	branches = branches/*:refs/remotes/git-svn/*

In the config file you see the “branches” line where it says all the directories in the “branches” directory will be linked as branches.

Instead of all branches let’s say we just want to pull down the branch named “branch1”. You would want to modify the line as below:

[svn-remote "svn"]
	url = https://git-svn-sample-project.googlecode.com/svn
	fetch = trunk:refs/remotes/git-svn/trunk
	branches = branches/{branch1}:refs/remotes/git-svn/*

Note that we replaced “*” with “{branch1}”, this way we are telling git svn to only fetch “branch1”. You can add more branches by adding the branch name in a comma separated list such as “{branch1,branch4}” etc.

Now we can tell git svn to fetch the code. To do so you run the “git svn fetch” command

$ git svn fetch

Git Basics
At this point you have a SVN project interfaced with git. You can run git commands on this repository such as “git commit”, “git revert”, “git diff” etc.

When you are ready to push your changes to SVN, you run the git svn dcommit command. Before you do that, make sure you run git svn rebase.

When you run the rebase command, it will rewind your changes, fetch the latest code from the remote server and then will apply your changes on top of it. If you have no conflicting changes it will go smoothly. However, if there are any conflicting changes, you will have to resolve those conflicts like in any version control system.

$ git svn rebase
$ git svn dcommit

Working with SVN branches
You can create a git branch that tracks the remote SVN branch as follows

$ git checkout -b branch2 refs/remotes/git-svn/branch2

Here we are creating a local branch named “branch2” which links to SVN branch named “branch2”. It is import that you maintain linear history on the branch. If you create other local branches off the SVN branch, you would want to rebase them so it has a linear history. If you have a non-linear history, changes will be there, however, you will lose the commit history that is on that non-linear part of the branch.

It is recommended to perform SVN branch merges on SVN instead of through git, as doing via git may result in changes getting pushed to the wrong branch, tree conflicts, etc.

You can find out more about working with branches here.

Hopefully you find this post helpful. You can find a more visual overview on my slides at slideshare.

Thank you,