A tale of three Git systems

Overview
Principal Developer Craig Marvelley compares three Git UIs to discover what’s most suitable for Box UK as we move over from Subversion.
Author
Craig Marvelley
Date

Update 25/10/2012: 

Updated commentary on Github’s installation process in response to comments made by Christian Johansen.

Moving to Git

Since decentralised version control became all the rage, at Box UK we’ve been making a steady transition from Subversion towards Git. Prior to beginning the move there was understandable concern that a new system for developers to learn, and changes to our deployment process, could harm productivity. In reality, however, the switch was smooth. We invested in training materials (including a few different books for our library, and the O’Reilly ‘Mastering Git‘ video tutorials which I’d particularly recommend) and employed a bunch of fresh-faced younglings who’d probably never even heard of Subversion (or, shudder, Accurev) and everyone got on quite well with things. 

GitHub

We use Redmine to provide collaborative features for our Subversion repositories – source browsing, issue tracking, code reviews etc. We were already familiar with GitHub, a similar solution for Git with added social networking features, and resolved to use it with our new VCS. At first we were only using GitHub for our open source offerings which meant that we didn’t have to worry about any financing (GitHub is free for open source projects), so we were up and running without having to bother anyone for a credit card, which is always welcome. Soon we decided to kickstart development of our OS libraries in private until they were ready for public consumption, so we upgraded to a private (paid) account. At this point we were using GitHub exclusively for developing and hosting our OSS projects, with repositories for our proprietary code remaining in Subversion.

GitHub
Box UK’s GitHub page

Searching for a scalable solution

After getting some Git experience under our belts we decided to use it for new proprietary projects too, but the repository cap on our GitHub plan initiated a search for an open-source solution that would allow us to scale without worrying about cost. That led us to…

Gitorious

At first glance a promising facsimile of GitHub, Gitorious was a leading candidate. Most of the features we appreciated in GitHub were present, including merge requests (or pull requests), team management and activity monitoring. The UI wasn’t as presentable, but it was functional. And crucially, we could install a local version within our network, which meant our repositories could be included in our existing backup solutions and wouldn’t be dependent on a third party.

Unfortunately the biggest problem we found was the installation process, which turned out to be tricky, mostly due to a lack of documentation and some difficult to resolve RubyGems dependencies. Once we had it set up, though, it served us well for around nine months, until we came across…

Gitlab

We didn’t have the option of Gitlab when we decided to go with Gitorious, but in the time that we were using the latter Gitlab went from strength to strength, adding features at a rate that outpaced its rival. Gitlab has a number of advantages over Gitorious. It runs on top of Gitolite, which furnishes the standard Git toolset with some powerful features like access control. This in turn allows Gitlab to offer features like protected branches, which fitted nicely with our ‘stable master’ approach to release management (where the master branch is fit to be deployed at any time) – protecting the master branch means no code can be merged to master without passing a code review by an authorised developer.

Gitlab in general was much closer to the GitHub-like solution we craved – open source, written in Ruby on Rails and hosted on GitHub itself (which opened the door for us to contribute back any features we added), and aside from a few niggles (a lack of fine-grained team management, and some annoying bugs around diffing code merges) it was much better received by the team than Gitorious had been. A timely release schedule (a release each month, at the time of writing) gave us heart that any issues we did encounter were not going to inconvenience us for long.

Gitlab
The Gitlab page for a Box UK app

Ultimately though, even though it worked well we decided that Gitlab wasn’t going to be suitable – as we had found with Gitorious, maintaining it proved to be a problem. Despite the superior installation process, this time saving was soon absorbed in having to upgrade Gitlab every month. Regular new features also mean regular regressions and bugs, which was something we couldn’t swallow given how important the component is to our development workflow. Ideally we wouldn’t have upgraded as regularly as each release, but as the product is relatively immature releases tend to contain must-have features.

Back to GitHub

We analysed the effort we were putting in to host our own solution and determined that it worked out cheaper for us to just upgrade our GitHub plan and move wholesale to that platform, especially when factoring in the excellence of critical features like code reviews and pull requests. It also meant we had a unified solution for all our Git projects, both open source and proprietary, which removed the potential for confusion. I miss the protected branch feature from Gitlab, but overall it’s a worthwhile trade off. Making a third party responsible for hosting the masters of one’s mission-critical code is a significant risk, but it is a risk we mitigate by scheduling regular “off-site” backups of the repositories.

Upgrading to GitHub was totally painless. We simply created repos on GitHub for everything we had on Gitlab, and mirrored them using a helper script:

#!/bin/bash

git clone –mirror git@gitlab.boxuk.net:$1

pushd $1.git

git push –mirror git@github.com:boxuk/$1.git

popd

This is the beauty of a distributed VCS: its very design makes changing a hosting solution incredibly easy. Within a day, all our projects were migrated, our Jenkins builds updated, and our developers were happily working with GitHub.

The conclusion

I wouldn’t recommend Gitorious at the moment; it has some catching up to do if it is to rival Gitlab as a local solution, though it does offer a hosted option too – but in that case I’d just go with GitHub from the off as it’s well worth the additional cost. Our feeling was that perhaps the Gitorious team haven’t made it as easy as they might for people to locally install the product in order to encourage paid hosted users – understandable perhaps, though it doesn’t help us in any fashion., but according to Christian Johansen, a Gitorious team member, Gitorious’ installation features were not deliberately deprioritised – please see his comment on the 22 Oct 2012 for more details.

I’d recommend Gitlab to anyone looking to self-host their Git management platform while requiring many of GitHub’s features, as long as the resource is available to support and manage it. It’s really suited for a group of 2-10 developers. It doesn’t support ‘public’ repositories so it’s also aimed at companies wanting to manage their proprietary code.

So, finally, with GitHub we appear to have settled on the best Git hosting solution for us. It seems you really do get what you pay for.

Any questions about any of these products? Leave a comment and I’ll do my best to answer them.

Comments

Add a comment

  • 21 Sep 2012 15:45

    Great to see the move to Git, and even better seeing the move to GitHub, a platform which I have much love for.

    The open source versions look great for those who have limitations such as requiring internally hosted solutions, but having seen the rate at which Github delivery feature additions I think you made the right choice!

    Here are some alternatives others have been using:

    http://beanstalkapp.com/ (less collaborative, but very “pretty”)

    http://www.codebasehq.com/ ( similar to github, with some great automated deployment features)

    Thanks for the post!

  • 21 Sep 2012 16:34

    We went through a very similar experience at my previous employer (campus-wide IT department for a large University.) We evaluated Gitorious, GitLab and GitHub (hosted) and GitHub (self-hosted).

    Ultimately, and commonly, upper management wasn’t comfortable with code being stored on servers outside our control so GitHub Hosted was out.

    This was about the time GitHub Enterprise rolled out, but we couldn’t get a whole lot of info from GitHub for sales questions and technical questions. I recall our sysadmins were also unhappy we couldn’t have root on the box or install out logging and backup utilities. The cost-per-seat/per-year on GitHub Enterprise also didn’t fly at the time given we were going through large budget cuts. So that was out.

    We settled on GitLab, as the team was about 8 developers at the time, and we looked at opening it up to the rest of campus developers to host their own private repositories. So we could have been serving some 40-50 developers eventually.

    The team is still using GitLab and are pretty happy with it, although they only use it for code/commit browsing and access control. The IT department already had a wiki (Confluence) and bug tracker (Jira) in place so we weren’t about to move those to GitLab for our projects, but other campus developers would find them useful.

    We, too, were bitten by regressions and bugs with the frequent release cycle, but they were features we needed. We didn’t have any strong Ruby devs on the team so troubleshooting problems was time consuming. In the long run I think GitLab will iron out and continue to get better.

    GitLab is a very viable solution and I wouldn’t hesitate to recommend it to companies wanting a self-hosted platform.

  • 21 Sep 2012 16:44

    I forgot about this one, which is a nice mix of collaborative tools and “pretty” UI : http://www.springloops.com/v2/

  • 25 Sep 2012 15:48 Box UK Staff

    @Dayle: Thanks for the links. I think we’ll end up keeping some sort of tool in-house for times when GitHub goes down (as was the case a few weeks ago) so we can keep doing code reviews, merges etc.

    @John: Yep, sounds like you had the same experience as us then :) We thought the same of Github enterprise, way too pricey – although given the way we’re eating up private repositories on Github we may need that sort of service soon.

    I wouldn’t have been disappointed if we’d stuck with Gitlab, and I’m glad it’s working out for you guys because it’s a good product and should get even better.

  • 22 Oct 2012 21:56

    Thanks for this article. The detailed overview and insight into your decisions is interesting as I am one of the people actively working on Gitorious.

    You seem to imply that we somehow made our software hard to install in order to get more paying customers. Nothing could be further from the truth. Gitorious was founded as a commercial company long after the initial development of the software, and by the time we started, the numerous components already made installation non-trivial. As a small team we had to focus on building a sustainable business first, in order to stick around for the long haul. Mix this with making new features, doing support and all that follows, the installation has sadly not been much prioritized.

    Just a few weeks ago we launched ready-to-ship VMs and a Puppet/CentOS-based installer on http://getgitorious.com. There’s more to come, but now installing a fresh copy of Gitorious can be done in less than 30 minutes on a blank VA, with no hassle.

  • 25 Oct 2012 13:21 Box UK Staff

    @Christian: Thanks for your comment. I understand now why the installation functionality has lagged behind the rest of the product, and am glad to hear that things are now improving. The new features sound promising, and should make a massive difference – I’ll hopefully be able to try the new installer in the near future, as I think there’s still a need for a good OSS solution.

    I’ve updated the article to reflect your comments, I hope that addresses your concerns. It wasn’t my intention to imply you were being underhand in any way, so please accept my apologies.

  • 25 Nov 2013 09:16

    GitLab.com co-founder here. Thank you Craig for the well written article. We are continually trying to make upgrading easier. We realize upgrading takes time and are continually improving the process. Since 6.0 there have been fewer regressions and it is now possible to upgrade a few minor versions in one go. And thanks to John Kary for sharing your experience with GitLab in the comments.

  • 27 Jan 2014 09:43

    We’re now at GitLab 6.5 and I think we’ve solve all the shortcomings in this article. We are no longer bound to Gitolite so Gitlab is easier to install. The releases are much more stable and with the new upgrade script upgrading is only a single command. GitLab groups provide a consistent way to manage teams. And since a few releases we have public and internal projects. If you want to update your article mentioning the above that would be great.

  • 26 Feb 2014 21:32

    I am using Gitorious at my old job and I had many difficulties but in 2012 the GitLab project doesn’t attracted me. When I tried updated it in the end of 2013 I saw that Gitlab was really more better but I don’t changed it. Today at my new job I’ll try use GitLab and I believe that is better. The GitLab’s rails version is edge and they are more updated.

    Sorry any English’s error.

  • 26 Feb 2014 21:45

    Thanks for commenting Steimntz! I’m glad you like it and see our improvement over time.

  • 14 Apr 2014 05:28

    This is a very helpful article. Thanks for sharing the journey your team has gone through.

Add your comment

If provided, we will link to this from your name