The Switch to Git

Apart from 9 months using Rational ClearCase (and a couple of dark years using SAP WCEM), I've used SVN as a source repository. I even use it for my personal development projects. So I feel pretty comfortable in the SVN paradigm.

The strength of SVN is its simplicity. It's fairly easy for any developer to pick up and master its basic functions. That said, it has some pretty major shortcomings in a collaborative environment:

• Everything goes to trunk - All the checks that go into ensuring quality code happen after the code is shared. A bad commit can break the build and hold up deployments.
• Branching is difficult - While it's possible to branch in SVN, it's a non-trivial process that's largely avoided in practice.
• It encourages sitting on code - The flip-side of a central repository and the difficulty of branching is that developers tend to sit on uncommitted code.
• Collaborating in an unfinished state is tricky - Committing unfinished code is risky because it breaks the source of truth. It encourages workarounds like emailing code or zipping up entire repositories.
• Code reviews are after the fact - .

None of those are showstoppers, of course, but something definitely feels amiss when you have to use alternatives to a collaborate tool to do what the collaborative tool is for.

So as part of our switch to a more agile framework, we took on migrating from SVN to Bitbucket. Most of our team hadn't used Git before (myself included!), so one issue with doing this would be the reskilling of developers in a new way of collaborating. So we needed a good reason to disrupt what people are familiar with. And with Bitbucket, these are the advantages I can see:

• Branching is easy - Creating branches in Git is a trivial process. Switching between branches is a trivial process. Working with branches can avoid prematurely merging code before it's ready.
• Integration with JIRA - JIRA Agile tickets can be used to create branches, as well as linking to commits against a number. This is good for chasing history.
• Commits don't need to worry about breaking the build - When working in a branch, checking in code that breaks the build doesn't affect the "source of truth". So developers don't have to keep code on their desk for fear of "polluting" the master code.
• Collaboration is made easier - Since multiple people can use the same branch, there's no need to resort to emailing code between developers.
• Master can be protected - Bitbucket can be set up so the only way into master is through a "pull request", and that can be protected by setting rules about code reviews, as well as ensuring the code will successfully compile.
• Code reviews are post commit, but pre-merge - Bitbucket puts code reviews as part of a pull request, so with the right rules only code that passes review will be put as part of the build.

This is not to say that all of it is easy. Git has a higher learning curve than SVN, and working with branches can be confusing. It's also hard to break out of the silos of development mindset that SVN encourages, thus robbing Git of the collaborative advantage it has over SVN. And no code tool is going to stop poor code from being committed.

That said, Git fits much better into the feature-driven development of scrum than SVN. It encourages keeping features discrete by their creation as branches, and keeps features from being prematurely deployed by keeping a master branch as the endpoint of development.