Gitlab vs Github

A little over a year ago, I finally got fed up with the numerous Github outages and switched us over to Gitlab. At the time, the move was incredibly painful. Gitlab’s UI was different, we had to modify our workflows, and the general anxiety around change made it a very charged topic. But we simply had no choice. Three weeks in a row, we had a major emergency, and we simply could not deploy a fix for hours at a time due to Github Actions either being flat out down or degraded.

It wasn’t just me; notice of of Github’s poor availability took the internet by storm, and eventually Github had to come out in front and make a public statement about this. Unfortunately, since that time it hasn’t gotten all that more stable.

In over one year at Gitlab, they had exactly 90 minutes of downtime. They’ve been incredibly stable, and we’ve actually come to love many of the features Gitlab offers over Github.

1. Gitlab lets you add top-level comments to an MR that isn’t tied to a specific file or line number. This has been truly invaluable. In github, you’re forced to add comments as you ‘submit a review’, and the replies aren’t threaded but quoted. So having long discussions about the merits of a change is fundamentally impossible. You’re forced to either talk in person or on Slack.
2. Gitlab pipelines are incredibly powerful and super flexible. You can actually determine at ‘compile time’ when certain pipelines get executed. In Github we’d often have to do complex if statements and bail with an early exit, but in Gitlab these pipelines would just never spin up to begin with. There’s a whole meta language around including pipelines into other pipelines and making units of work far more composable.
3. We can easily add labels, reviewers, and so much more right in the MR description! When I create an MR with /label ~qa-needed and click Submit, it automatically strips out that sentence from the description and adds a label to the MR! We’ve built so many cool automations around this, and I find I really miss this when going back to Github.
4. Stability. ‘Nuff said.

Gitlab also has its flaws though.

1. Subgroups members always inherit the parent group — this is very annoying. We ended up having to write custom logic to filter out parent group members when dealing with code review notifications

2. When a merge train fails due to flaky CI, there’s no easy way to retry!

You have to push up an empty commit, have the original build re-validate, and then try and merge again. It really slows the development process.

3. Mobile web support

These days I code less and less, but I still am tagged on quite a few reviews because I have a lot of context from the early days of Motion, and I wrote a lot of the underlying code quite frankly. I used to do nearly all my code reviews on the go, on mobile web. Gitlab, however, seems to have a very bizzare bug where I have to sign in every time. No matter how many times I click ‘remember me’, it simply never does.

4. General lack of responsiveness for highly requested features, aka death by a thousand paper cuts.

Over and over we’d run into three, four, or even five year old suggestions that were simply never acted upon. Being able to customize auto-collapsing diffs on large file changes like yarn.lock files. If you’re a member of a subgroup and you’re missing a review from a parent or sibling group, you don’t even know who to reach out to get an approval! Complex merge order dependencies still haven’t been solved, so nobody can ever write something like Graphite on the Gitlab platform. We wanted to show test coverage in all MRs, but of course there’s a 3+ year old issue that prevents us from doing so. We can’t filter pipeline jobs by the name, so finding the pipeline that failed is basically impossible if you don’t have a link for it. We can’t add a group as a reviewer, so we have to manually add the people from that group. Maintainers / owners can’t override CI permissions on merge requests, like they can in Github, in the case of emergencies. We can’t search for a commit sha in a commit list, so when we’re using ArgoCD to tag commits, it’s basically useless. Still no Slack notifications — first requested 6 years ago. Intelligent cache pushing missing.

These aren’t fake examples by the way — they’re the actual links taken from our internal Slack channels. There’s 27 such examples, and of course no single one makes Gitlab unusable, but when taken as an aggregate it’s really painful. “Hey this one is pretty new! only 3 years old” basically became a running meme.

Ultimately, competition is great for the ecosystem, and while Gitlab has its warts, it also has its upsides. If you’re a large company where stability matters the most, and you have the resources to build custom UI’s on top of Gitlab (they have an amazing API — flat out better than Github’s), then the numerous papercuts quite frankly just don’t matter. You can make your own pipeline search dashboard, or your own review experience just on top of their API. If you need true, full-fledged customization, then Gitlab is definitely a superior product. There’s a reason that most large companies, once they switch to Gitlab, usually never go back!

For most startups who just want to get up and running, it makes sense to stay (or start) on Github, since it’s where most of the ecosystem is. It’s way more accessible, tools like Graphite and others are always going to target Github first. Quite frankly, if you’re truly a small stage startup then the occasional stability hit isn’t that big of a deal (was your team of 3 really going to merge that many PRs on any given day anyway?).

Overall, come into Gitlab with an open mind, and be clear about exactly what outcomes you’re hoping to achieve. Depending on your situation, it’s not nearly as ‘crazy’ of a choice as Twitter would have you believe.