Getting to grips with Git
6th March 2013
I sat down to my first interview with GCD Technologies just over a year ago. It was an interesting experience – part interview, part chat, part pummelling for information about Git…
In retrospect it was obvious – I had used Git and they were interested to know what my experience with it had been like. They were heavily invested in Subversion and had been for quite some time, yet they were mighty interested in my opinion of Git. My opinion was simple – Git is a much better fit to the way I worked and I felt it could be the same for GCD.
Whilst I had used Subversion before I was pleased to start my first day with the news that GCD was intending to trial the use of Git. Even better, the first project in the trial would be my first project with the company so I wasn’t having to re-immerse myself in Subversion for a while yet.
One immediate advantage to adopting Git was that there was no real need to get too worried about server infrastructure. Getting started was as simple as creating a new project in Xcode and ticking the box marked “Create local git repository for this project”. After a few days of local commits we needed to start collaborating so we looked at the options available to us.
As Git is a distributed version control system (DVCS) we considered hosting a repo on a local machine – connecting in via SSH to push and pull commits – but it would have been foolish to overlook the availability of providers such as GitHub, Bitbucket and Beanstalk. While the popularity of GitHub had an obvious appeal, we elected to go with Bitbucket simply because we were able to create free private repositories with multiples users for the trial – something neither GitHub nor Beanstalk provided (and still don’t).
The first few weeks were a somewhat timid affair – we each worked primarily on our master branches, pushing regularly and hoping to avoid collisions. It wasn’t long before we realised that we really weren’t taking advantage of the power that Git’s low-cost branching model offered us. We quickly jumped on the idea of working on feature branches allowing us to start pushing our features up to Bitbucket so that we could keep up with each others’ work. The natural evolution to this was to adopt a pull request-based workflow in order to start performing code reviews.
Pull requests are an extremely compelling feature of services like Bitbucket and GitHub. While code reviewing is a common practice across many version control systems, the combination of integrated commenting systems and readily merged branches have really helped propel the popularity of Git.
The efficacy of the pull request system can also make or break a service. After a few months of working with Bitbucket we hit a limitation – it wasn’t possible to comment on individual lines of code in a pull request. Combined with a few service outages, this caused us to reconsider our decision to go with Bitbucket.
By this point the trial was deemed to have been successful. Our small team that had started out using Git could regularly be found extolling its virtues to anyone they could corner. Despite the danger of becoming VCS bores we successfully conveyed the key benefits to the rest of the company and it wasn’t long before we had an official GitHub account and were putting our money where our mouths were.
All current projects were migrated over to GitHub and the process of creating feature branches destined to be code reviewed and merged back in by pull request became a standard part of our workflow. We’ve seen immediate benefits from this: our coding is less of a solitary affair and more of a social experience.
People are sharing tips, tricks and advice and it’s fair to say that code quality is improving as a direct result. Bugs are being caught much quicker because we are able to check out code and run it locally for testing. While this could have been done with Subversion, the process of creating a branch and getting it merged back in was seen as a thing to fear. Branch creation and merging in Git has much less stigma attached, and suddenly branching has become the norm instead of the exception.
In some circles its considered that unless your using Git on the command line you simply not doing it right. While it is true that the command line is where Git was born and probably the only place where you can utilise all its features, we found a variety of GUI clients which make a lot of day to day tasks quicker and easier. SmartGit became a quick favourite for Windows users, while those of us running OS X were quick to jump on the excellent Tower client. It has a strange limitation of not being able to display the contents of more than one repository at a time, but the ability to drag and drop branches to perform actions like branching, merging, publishing and pushing make it a refreshing change from having to remember all the command line syntax.
Using a service like GitHub means that we no longer needed to invest as much time and infrastructure in order to maintain a local Subversion repository. This saves development time as the burden of server maintenance was removed. The fact that each project was a separate repository meant that we no longer had a single point of failure – if our Subversion repository was corrupted, everything was halted until we got the backups sorted. Even if a service like GitHub goes down for a while the distributed nature of Git means that we’ve got at least one full copy of any repo in the office that can be shared out if necessary.
It’s fair to say that we’re now firmly a Git shop. We still have our moments where the power and flexibility catches us out and submodules have taken a little bit of getting used to when moving from Subversion externals. On the whole the process of switching has been fast and successful. Our advice to anyone who is considering moving from an older centralised version control system (like Subversion, Perforce, or CVS) is simple – give Git a trial and you won’t have any regrets – we don’t!