How to start using Git in SVN-based organization
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
(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
Alexander Beletsky replied on Thu, 2011/07/07 - 1:41am
in response to:
Gil Collins
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
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