Git Svn

Last week I started working for my new company and like most of the IT businesses today, we are running subversion for Source Control Management (SCM). While we are still discussing, moving to a Distributed SCM (DSCM), I didn't want to lose the advantages of working with git. Remembering Samuel's talk at Java User Group Karlsruhe and with a hint from Ollie, I started using git-svn.

The git manual describes the svn capabilities as follows:

git svn is a simple conduit for changesets between Subversion and git. It provides a bidirectional flow of changes between a Subversion and a git repository.

git svn can track a standard Subversion repository....Once tracking a Subversion repository (with any of the above methods), the git repository can be updated from Subversion by the fetch command and Subversion updated from git by the dcommit command.

You can create a fully featured git repository from the trunk of a subversion repo with the following command:

git svn init -T https://svn.hostname.de/svn/projects/project/trunk

The git repository, that you just created is hooked to the trunk, passed with URL in the command. To get the HEAD, just run:

git svn fetch

Now you are ready to work with git, as if you had cloned a repo from GitHub. You can work with branches locally and commit your changes offline. When you want to share your work and push it back to subversion, you can use the following command:

git svn dcommit

You might ask yourself how to get the latest changes from your fellow developers? First, you should have no un-commited changes when you run:

git svn rebase

The reason for that, is this command is similar to svn update. It uses git-rebase instead of git-merge, in order to preserves linear history.

Those couple of commands got me started in no time and I didn't have to wait for a company-wide repository in order to have all the advantages that come with git.