Channels ▼


Migrating from Subversion to Git and the Lessons Learned

3. Your team will need "Git champions"

Let me say this once again: Git is different from SVN, and it can take a while for people to adapt. No matter how much you prepare or how much you educate, developers will run into issues when they start actually using it. Left unattended, these issues will reduce productivity and can spiral into hostility to change.

We marked a couple of developers who had Git experience as "Git champions" after the move. Any time people had issues — didn't understand something or just wanted to ask, "What did I just do?" or "How did it work?" — they could pull in a Git champion to help them. This was critical to making the change as seamless as possible.

In practice, we found the major difficulty people encountered was not the differences between commands, but the differences in the conceptual model of working copy, local repository, and remote repository. Developers had internalized the SVN model. I would say it took two to six weeks for each developer to reach the same familiarity with Git.

4. Don't change your workflows too much too quickly

There are really advanced Git workflows that allow you to put the "D" in DVCS. Branches, feature branches, forks, and pull requests are just the start. If you switch to these advanced workflows at the same time as you migrate, you are setting yourself up for a fall. We took the principle of "success through stability" into our workflows as well. We started off with exactly the same workflow we used in SVN:

  • One or two stable branches for bug fixes; and
  • A master branch for new development work

As I mentioned before, our SVN workflow for getting bug fixes from stable to trunk was to manually patch each commit. We kept this workflow when first migrating to Git — each bug-fix commit was manually cherry-picked into the master. Git is designed for merging and this was part of the reason we migrated.

5. When you are ready, make small, iterative workflow changes

We made our first workflow change about two months after the migration. Again, we invested in communicating this change to the team (the rationale, and the series of steps needed). We reactivated the Git champions to assist people anytime they had a difficulty. It proved to be a smooth, easy transition. Making small, understandable, iterative changes is what made each change a success.

The Current State of Play: Distributed VCS, Decentralized Development

Once we had settled into a merging workflow, we started embracing the distributed workflows that Git enables.

I mentioned earlier that one of our major products, JIRA, now releases to our hosted platform every two weeks. We tend to run with separate teams in separate branches; this enables frequent releases by decoupling separate teams' work from each other:

  • On the day-to-day level, one team's changes do not impact other teams. Did Team A break the build? That's not a problem. Their changes are isolated to their own team; they broke only their own build and no other team's development speed is affected.
  • On the release level, one team not making the cut does not affect the release. If Team B did not get all their stories over the line, they do not merge back at the end of their iteration. The release can go ahead with everything except Team B's stories.

This change does introduce challenges of its own. Merging multiple sets of changes at the end of an iteration runs the risk of integration conflicts that can cause defects. In practice, this is mitigated by the fact that individual teams tend to be working on separate areas of the code base. However, teams do work on areas that are likely to conflict, and they tend to work directly on the master branch. The teams that are running on individual branches pull regularly from the master to get these changes and catch conflicts before they become critical. Thus far, keeping the lines of communication open has prevented these sorts of conflicts from becoming problematic.

Another complicating factor is geography. JIRA development is done in Sydney and Gdansk; but on any one day, we might get commits from Atlassian teams in San Francisco, Boulder, or Amsterdam. Teams in different cities tend to run on different branches, allowing us to get over the communication gap. To facilitate communicating about potential conflicts, we use HipChat (our group chat product) for 1-1 and group announcements and communication; this works well for our distributed team members. The real-time chat rooms keep conversations persistent, so when someone logs in from a different time zone, they can check the status of the conversation and get quickly up to speed. Developers are pinged when they are mentioned in a room, so they can respond to someone's query without having to read through the whole conversation.

A quick note on branch strategies: Some people advocate a branch-per-feature workflow, where each individual story is developed on a feature branch. This is a great workflow if it fits your project. Some products at Atlassian use this. In JIRA, our CI overhead is very high. Running what we would consider "adequate" CI on every story that gets developed is not realistic for us. Branch-per-team as a workflow, however, is working out well for us.


The migration turned out to be a great success.No developer time was lost in limbo where they could not commit. CI ran continually, and we maintained the ability to do a 5.0 release throughout the entire migration. Post migration, we managed each change successfully, and today, developers are embracing the power that DVCS gives them. The proof of this is in the complete change in our release cadence. There is no way we could have shifted from a 90-day to 14-day release cycle without DVCS.

This is probably the fifth time I have mentioned it, but I cannot stress enough the importance of communication to the rest of your development team. During the migration, do not be afraid of giving it a higher importance than the actual technical migration tasks. Communication helps the developers own the change. For those reluctant to change, communication decreases worry and helps developers embrace DVCS. And isn't that the goal?

Jonathon Creenaune is a team lead at Atlassian. He's worked extensively on the server but now focuses on building rich browser clients.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.