How we switched from Subversion to Git
So I heard about these strange distributed version control systems like over a year ago. I used it in my own little projects and everything went smoothly and I really liked it.
The idea also caught on at work and my team started a using Git in a fresh project last summer. We did not had so much problems since you can use Git very much like a central vcs like Subversion if you want to.
Still, for all other code, we used Subversion.
We believe in agile and feature branches, so that's what we do a lot. Every story has its own branch. If one story touches multiple code bases, that means multiple merge down/copy up's.
At some point, in preparation for a sprint review, we found that code had disappeared from the trunk. Everything seems to work perfectly, just this feature was missing. Usually you would think if code was deleted, there would be at least one test failing and telling you that something is missing. But no, typing one wrong version number during merge down/copy up cut out the story very cleanly. Once we found the problem we could merged it back in from the not yet deleted feature branch.
Overall we managed to work with Subversion but it was a growing pain since we knew there was something better.
There are several advantages of distributed version control system which you all might have heard of already so I won't go in to detail of this (of course there is also one major disadvantage: complexity). The main advantages for me are:
- Everything is local - very fast
- Merging is much much easier (or updating from another repo)
- Because merging is easier I tend to branch more often to try out ideas
Technology
Here is our setup what we use at work:
The OS: Windows and Mac
Basically no surprise here. Works on both machines.
The IDE: IntelliJ Idea 9
Idea does support Git. I do like the approach which they took to simply use the git binary of your operating system. With the version control console you can see what Idea is doing. This way you can watch and learn. Back with subversion we had sometimes trouble using two different tools for handling subversion problems, like Idea and Tortoise SVN. Using the same tool for everything will make it easier. The Git integration is not perfect but it does work well.
Continuous Integration: Teamcity
Teamcity does support Git the same way as Subversion. There is one drawback however: Pre-Tested checkins are not supported yet. This cool features allows you to run all tests before checking in. You will never have a broken branch/trunk if you use it! Basically it will take your changes to the code base, runs all tests and only commits them if everything passes. Sadly, it does not work with Git (yet, but you can vote for this feature). Teamcity does allow you however to do a remote run with the changes you committed locally. So you check in everything locally and while Teamcity runs all the tests you can keep on coding. Running all tests with your current changes in the change list is also supported. Teamcity uses JGit and has some limitations (like no tagging support). In Teamcity 5.1 they want to use the Git binary as well.
Another problem, which I will talk about in the next section, is agent side checkout.
Build Tool: Maven
Maven supports git as scm. Nothing more to say.
Since we are releasing our software every other week we automated the build process to two stages. Building the release and packaging different build artifacts. We used to have a button in Teamcity, push it and 30 minutes later we had a release. Unfortunately the way Teamcity supports Git is that the code which will get checkout does not have a .git directory (and for maven it is not under source control). I still wonder what the heck they are doing there. Without that, maven can not advance the version numbers in your pom and you are stuck. Please go and vote for this feature now. Thanks. Until then we just do it like in the good old times and do a maven release from the command line.
People
While everything so far was technical, the biggest challenge might be mindset of the people and support from your friendly manager.
I’m lucky that my boss is very hands on and really liked that idea (also, since he was the one we usually asked if we yet again had problems with Subversion properties being messed up somehow). Otherwise you might need to do some ROI calculation why this really is a good idea.
What I encourage is that every team needs to have 1 or 2 people interested in git. The others in the team should see the benefit of it, even though they don’t know how git works. My advice would be that one person would give a 20 minutes presentation of what you can do with it to all interested co workers. We did not do it, but looking back, we should have done it. Make sure that you bring across the message that switching scm’s will not be that easy. If possible make everyone read the first 3 chapters of the freely available Pro Git book (and also buy a copy or two for the library). This will give them a much better understanding. It is change and change usually causes some trouble. We got a team commitment for it so at least nobody was opposed to it. If a couple of people are not happy with the way how the new things are around here, they will have an easy time to make a loud and clear statement that switching to Git was a bad idea. Git is more complex but also more powerful.
I did a plan on how to migrate. This took me just a couple of hours.
Plan and test these as much as you can. We started to use git just to discover that we missed some use cases like our automated runs to check the external web service dependencies. Two people doing the planning certainly helps.
After start using it, we had one guy (me) who went around for the first 2-3 days and helped people with their git related problems. There will be problems, I promise!
We did migrate all of our code at once since we did not want to be stuck between two vcs’s. We will go with Gitorius and ssh based authentication. Since we do not have a server for that (yet) we use a shared drive for the time being as a repository. Being distributed it will be no problem for Git to change it’s location later on.
The first two of days were a bit tricky but it got much smoother after we all got used to it.
The work flow is different and it will take some time until everybody takes advantages of all the features like commit your files more often or make more private branches to try out ideas. We started with a similar work flow we are used to and plan to introduce one feature of git at a time. This could have been better. Iron out the known commit habits with Git and make sure this works in your favorite IDE before hand. It is very important to make the transition a better experience.
We started just this month but we already had some nice effects like merging two branches with renamed files. On guy changed file and somebody else renamed the same file in his repository. As he merged in the changes, the change appeared in the renamed file. Really great.
Do you use a distributed version control system? How did your transition go ?