Migrating from SVN to Git; How we did it
My team migrated from SVN to Git about 3 months ago. After a few tweaks, a few bugs and a little elbow grease we’ve been stable ever since. And you know what? It was one of the best moves we’ve ever made. Developers are more efficient and we have finally documented and streamlined our release workflow.
I was in charge of handling the migration. That included setting up an internal Git host, migrating the SVN repositories over, documenting the new Git development process and training the developers. One important requirement was that we couldn’t stop active development during the migration – developers always had to have a place to commit code.
Technical Side – What tools were used and how was it done?
Stash
Due to legal reasons, we weren’t able to make use of popular Git hosts such as GitHub or Bitbucket, so we needed to find an internal hosting solution. We looked at many open source hosts, along with GitHub Enterprise, and finally determined that Atlassian Stash was the best option for us. It offered most of the features we desired – internally hosted, pull requests, HTTP/HTTPS/SSH access, and the ability to connect with Active Directory – and was corporate backed and reasonably priced.
Other than the setup being archaic Stash was up and running within 20 minutes. Configuration was relatively trivial, and mostly included configuring permissions and user setup. We hooked up Stash with Active Directory so all employees can login using their domain accounts. This reduces the number of username/password pairs everyone has to remember which, imo, is a really good thing.
Initial SVN Migration
The initial SVN migration went relatively smoothly with little to no hiccups. We followed the steps I layed out in my previous post, Migrating from SVN to Git, with one small caveat – after we performed the first fetch, we left SVN as the primary repository, and all code was still committed there. We set the permissions on the Git server to be readonly so that developers could clone the repositories, get introduced and familiar to Git, and we could confirm that there were no connection or permission issues with Stash. Everyday we performed a fetch from the SVN repository and pushed the changes up to Git to keep things up to date. We left this process in place for about a week; once we confirmed there were no issues, and all devs had some sort of Git client they liked, we switched over. (As a side note, if we had many more repositories, and/or were going to leave this process in place for longer than a week, I would have set up a job to run daily (perhaps hourly?) to perform the fetch. If you’re in this boat, I recommend you do that using Powershell or similar, unless you like performing the same monotonous task every morning, in which case go for it.)
When we were ready to shut off SVN, we had all developers commit any pending changes to SVN, then we switched the repository to be readonly. We performed one final fetch/push from SVN, and opened up the Git server to the world. (Okay, opened to our office, but whatever.)
Tools
So we set up Stash on the server, but what clients did we use? We are a Microsoft shop, and as such have a mix between SourceTree, Posh-Git and bash. We didn’t really set any limitations on what client to use, as long as it works for the dev. (If you ask me, though, Posh-Git is the way to go. By a mile.)
Human Side – Git workflow, developer training and hiccups
Git Workflow
This is where the fun starts. Developers inevitably had questions, most of which I could answer but some of which we had to work out together. Most of these questions revolved around workflow – when do I branch, why do I branch, do I need to branch? Our SVN workflow was, well, not exactly much of a workflow. We had a develop branch, and most work went into that, and sometimes we would branch for features, but then we would have merge problems because SVN sucks at that, and then we’d release whenever from wherever, and… yeah. Not much of a workflow.
So, I took this opportunity to standardize our process, which is basically git-flow. We have a develop branch, all features get branched from there and merged back when they’re ready. When we decide to release, we branch into a release branch, perform fixes, and merge the production ready code into master. Hotfixes are merged off of master and merged back into master and develop. I laid this workflow out in a formal document that was available to everyone – developer or otherwise.
The fun part about documents, at least that I have found, is that nobody reads them. Ever. I still got a lot of questions about where to branch feature branches from, when to create a release branch, and where to release from. My answer, most of the time, was “read the documentation” (without being rude) to which I got a “what documentation?” response.
Training
So the next logical step was group training. I set aside 30 minutes to get all developers together and explain things – both about Git and the new workflow. We went over the differences and similarities between SVN and Git – what distributed means in practice, pushing, pulling, committing, stashing, adding it items to the index, etc. And then we covered the new workflow (with pictures!) and how Stash helps formalize the process with Pull Requests and such.
The training was a huge success even with it only being a 30 minute session. Everyone was able to ask questions and get on the same page. I highly advise giving a formal presentation if you can with as many visual aids as possible. It’s much easier to understand a live, visual presentation over emails and a Word document.
Issues
We luckily didn’t run into any technical issues. The only slight issue we ran into was getting developers to follow the new workflow. Again, training pretty much mitigated this issue and everything was smoothed out in a matter of days. We have yet to have any technical issues.
Wrap Up
If you’re on the fence about making the switch to Git, I highly recommend it. There are many benefits with little to no drawbacks. We’ve only been using it for 3 months and I can already see an increase in productivity and quality of output. Formal Pull Requests have strengthened our peer reviews and having a strict release process has increased our quality. It has been one of the best decisions we’ve made as a team in a long time.