I'm software developer and microISV, with a lot of passion to technologies.. having a fun writing code, writing blog posts and giving public speeches. For about 10 years of total experince I've been working in many branches of software development, including management and QA. I try to follow and adopt agile practices and signed up for software craftsmenship manifesto. Alexander is a DZone MVB and is not an employee of DZone and has posted 67 posts at DZone. You can read more from them at their website. View Full User Profile

How to start using Git in SVN-based organization

07.05.2011
| 18668 views |
  • submit to reddit

I've been using Git about a year now, immediately after creation my github account. I got really nice impression of using this tool, but still - on my primary job at e-conomic we are using SVN as primary VCS tool.

You are probably aware about all good thing with Git. If you still don't you might check out these great answers on Stackoverflow. In short - Git adds benefits, but it adds complexity as well.

After a bit evaluation I found that those benefits are worth to stop using SVN and switch to Git. But, if you ask your colleagues "Are you ready to go with Git?" you would probably hear "No!". It is clear why, people are getting used to current tools.. infrastructure are build around them. And switching from one VCS to another seemed as destruction of building fundament for many developers.

Fortunately, Git has a killer feature that other DVCS does not have! And this feature will help you to smoothly start with Git even if your company is still using SVN as standard. Yes, I'm talking about git-svn.

Believe me, it is amazing! I always have a little distrust for such kind of integration tool, but so far it works as charm. So, I'll give you a small instructions that will make you possible to get to your office tomorrow and start use Git as your own VCS.

Setup you environment

  • Download and install msysgit
  • Setup local user information, example
        git config --global user.name “alexander.beletsky”
        git config --global user.email “alexander.beletsky@gmail.com”
    
  • If you are on Windows and doing only-Windows development, it is recommended to turn off autocrlf
        git config core.autocrlf false
    

Checking out code from SVN repository

  • Run git clone command (it might take some time, depending on repository and history size)
        git svn clone https://mysvnserver/repo 
    

As clone finished, you will see that new folder repo created with the content of your SVN repository. Now, this folder is actually Git repository + you local sources copy. Try to run git log inside the repository and you will see that all your history are there!

Let's do some work

Now, suppose you start to work on some bugfix. By default, git repository contains one branch called master. Good style is do not do direct commits into master at all, just keep it as synchronization point between SVN repository and your local repository. So, to do actual job you to create branch.

    git checkout -b bugfix-id-1453

This command will create new branch called bugfix-id-1453 and immediately switch to it. If you haven't noticed how that happened - please welcome to git's high performance world.

You changed some file and ready to commit. In git it's a 2 steps operation. First, you need to put content to stage.. second, you store the content in new commit object.

    git add .
    git commit -m "issue has been fixed"

Commit changes back to SVN

You've fixed a bug and now fixed is placed in bugfix-id-1453. But you should give it back to rest of the world.

Checkout your master branch:

    git checkout master

Get the latest changes from SVN:

    git svn rebase

Now SVN server and local master branch are identical. We have to merge our fix into master:

    git merge bugfix-id-1453

Now master contains previous SVN state + new fix. We have to synchronize local repository and SVN server:

    git svn dcommit

Conclusions

Git-svn is perfect tool to start using git without radical changes in organization. It gives everybody change to try it out, how much it really fits your needs. I'm having a big pleasure now of working with Git. I'm not saying it's ideal smooth process, sure I met some difficulties. But for me those difficulties are nothing comparing the benefits I'm getting with it.

 

From http://www.beletsky.net/2011/06/how-to-start-using-git-in-svn-based.html

Published at DZone with permission of Alexander Beletsky, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Jilles Van Gurp replied on Tue, 2011/07/05 - 12:52am

I actually did this at work as well. I started early last year. Within a week I figured out I got most of the advantages of using git while using git svn without much of the disadvantages. This made me very happy and I have not really looked back since.

Then the next step was basically making my colleagues aware that they were being backwards. You do this by emphasizing git's advantages when your colleagues are struggling with some nasty merge conflicts or when some non trivial refactoring is under way (both of which are situations where git and git-svn shine).

It took me about six months to get most of the team on git-svn as well. But we still had some central svn based infrastructure that we needed to use. Now at this point, this disn't matter as much. Git and git-svn are decentralized and having a svn node in the distributed network of repositories is not a big deal (although you want to be careful with svn branches and tags).

Luckily my company started deploying git based infrastructure a few months ago. As soon as I discovered this, the decision was a foregone conclusion. So, I git svn cloned a clean copy of our svn repository; git pushed it to the new git repository and switched over my local git config to point at its new master. Migration done. Everyone moved over, no discussion.

 

Fab Mars replied on Tue, 2011/07/05 - 3:41pm

How to start using Git in SVN-based organization?

Use git-svn as you smartly explained, do your local branches, your local commits, work with fluidity, push when you are ready...in other words do efficient work, whilst the others deal with merge-nightmares ahahah.

Gil Collins replied on Wed, 2011/07/06 - 8:27am

Great article I just have a few questions.

How do you deal with having multiple branches checked out in order to merge code from one SVN branch to another when using git svn ?

Say for example I have SVN branch 1a and 2a, I have some code I need to merge from one to another can you have two or more local branches checked out at the same time in order to migrate code from one to the other?

Also what is the best way to perform the "git svn clone" it seems to take a very long time, after it's done once can it be copied to another machine and used or does every person that wants to use git have to perform this operation?

Alexander Beletsky replied on Thu, 2011/07/07 - 1:36am in response to: Jilles Van Gurp

It seems to be I'm exactly at the beginning of your path! As I've stated month ago, now 4 people in organization are using git-svn and pretty happy about it. I don't believe we can get rid of central SVN repository fast. So, like in your case it might take year to: gather all required experience, motivate the rest of people to use Git, switch to Git completely.

Alexander Beletsky replied on Thu, 2011/07/07 - 1:41am in response to: Gil Collins

Thanks, great questions! I'm about to do several blog posts exaclty on this topic, so stay tuned! Short answers - it is possible and no hard to do, we are having a lot of branches in SVN repo, switching from one branch to another at the end of iteration. Regarding "git clone" - yes it could be a little long (but what I see it it not longer then clean "svn checkout"). And sure, once repostiory is cloned you can share with other developers just by copining it! Great advantage of git as you hold reposiotory + working copy just in one place!

Gil Collins replied on Thu, 2011/07/07 - 7:47am

In your repository are you using the structure trunk/, tags/ and branches/ ? Or do you have one project per repository or some other format? I've seen in other articles that when the clone is performed it's typically in this form when used with an SVN repository :

git svn clone http://server/repo/<path to project> <path to local directory> -T trunk -b branches -t tags

Or do you find that you don't need to define this structure?

I'm just trying to figure out how your project example relates to my own.

Thank you for your help,

Alexander Beletsky replied on Thu, 2011/07/07 - 1:29pm in response to: Gil Collins

Yes, it is standard trunk/ tags/ branches/. What I did is just clone existing branch. As soon as I need some another branch to work, I could add that easily to existing repository.

Gil Collins replied on Fri, 2011/07/08 - 8:36am

Will adding the branches and tags later associate them with the existing projects or make them their own projects in the git repository. I know that when you use the clone with -s or (-T, -b, -t) then it shows those branches and tags as part of the structure of the main project.

Thank you for you answers, looking forward to seeing your next articles.

Christoph Kutzinski replied on Wed, 2011/07/27 - 8:37am

Github warns about using merge, when working with git svn http://learn.github.com/p/git-svn.html

Did you make any experience with that? Did you have any problems when dcommitting merge commits?

Sirikant Noori replied on Sun, 2012/01/15 - 11:45am

If you want "git svn dcommit" to replay the individual commits back to svn, you'll have to rebase the topic branch on the master branch and then do a fast-forward merge back onto the master.  Otherwise you'll likely get a single "squashed" commit back into svn and you'll be left with a dangling topic branch.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.