Many people ask me: “Which distributed version control system should I use for my programming project, GitHub or GitLab?” It’s not that simple a question. Let’s break it down, shall we?
First, do you really need a distributed version control system (VCS) at all? A VCS’s (aka a Source Code Management (SCM) system) job is to make it easy for multiple developers, designers, and team members to work together on the same project. It ensures everyone has the same access to the latest code and modifications are tracked.
That’s easier said than done.
That’s why Linus Torvalds thinks of Git, as his other great invention. Git is free, open-source, and fast. It also works better than its predecessors, such as Apache Subversion, Concurrent Versions System (CVS), Perforce, and Rational ClearCase. There’s a reason why so many VCS services have “Git” in their names.
Of course, you can use Git by itself on your own server. If all you’re doing is building a program in-house, a local Git instance is all you need. You can also use Git as a centralized VCS on your own servers or cloud. There’s no need to subscribe to a VCS service when you can build your own. With this model, you can easily run a project with your team and partners scattered throughout the world.
If you do need the bells and whistles of a hosted Git service, however, then it’s time to look at GitHub and GitLab.
GitHub is the oldest of the services. It was developed by Chris Wanstrath, P. J. Hyett, Tom Preston-Werner, and Scott Chacon using Ruby on Rails in February 2008. Because of its first-mover advantage, GitHub became the home base of many open-source code repositories.
GitLab came later; Ukrainian developers Dmitriy Zaporozhets and Valery Sizov created GitLab in 2011. From day one, GitLab was designed to be a set of collaboration tools as well as a code repository service.
Still, they look more like each other than not. Both run on Linux servers, come with issue trackers, and offer a wide range of third-party integrations and import tools.
They also both have command-line interfaces (CLI) for advanced developers, and they also offer Web-based interfaces for new programmers. In GitLab’s case, the user interface uses GitLabs’ own Pajamas design system and is written in Vue.js. GitHub’s user interface, Desktop, is available as a Windows or macOS program. You can also now use Visual Studio with GitHub
While both support open-source, the repositories themselves use a mixed programming model. GitLab used an open-core business approach. In this model, the GitLab Community Edition remains free and open-source, while the GitLab Enterprise Edition has more features and comes with support. As for GitHub, while its code contains some open-source code, it’s not an open-source project.
Still, fundamentally, both offer web-based repositories with open-source, Git-based code management and local file changes with a remote repository. If all you want is basic Git functionality but with someone else to worry over keeping Git up and running, either service will do well for you.
Of course, some people still dislike GitHub because Microsoft acquired it in 2018. To some, Microsoft will always be The Evil Empire, no matter how much Microsoft shows it now supports open-source methods and software — or how often Microsoft CEO Satya Nadella says he loves Linux. That said, that’s never been that big a factor. While some users did flee GitHub for GitLab and Atlassian BitBucket at the time, it was never the mass exodus some had expected.
That said, GitHub is clearly the 800-pound gorilla of the VCS world. According to the programming tools company JetBrains, 77% of developers use GitHub regularly compared to 40% for GitLab and 25% for BitBucket.
The core difference is GitLab has Continuous Integration/Continuous Delivery (CI/CD) and DevOps workflows built-in. GitHub lets you work with the CI/CD tools of your choice, but you’ll need to integrate them yourself. Typically, GitHub users work with a third-party CI program such as Jenkins, CircleCI, or TravisCI.
Another important difference is GitHub puts speed first, while GitLab focuses on reliability.
Specifically, GitHub advocates merging new branches with the master branch. That way, you’re already ready to quickly deploy, while you also speedily reinstate your old version if something goes awry.
In GitLab’s workflow, you create multiple stable branches beyond the master. At a minimum, you’ll have production and pre-production stable branches. This means you’ll need to go through a multiple-step testing process. A single code review upon the merge request isn’t enough.
Of course, you can make either one work the way you want, but there’s a clear difference in the preferred approach.
Another core difference is that GitLab offers you a complete software development solution. They advertise themselves as a complete DevOps platform for a reason. That said, GitLab does offer integrations with some third-party programs and platforms such as Jira, Microsoft Teams, Slack, Gmail, and numerous other apps and platforms.
GitHub, on the other hand, offers fewer services within its own program but offers ways to integrate with many outside programs and services. These include software that GitHub has worked on to integrate with the service and hundreds of other programs via GitHub Marketplace.
Both services offer free plans. These come with unlimited public and private repositories. That may be enough for you if you’re a solo programmer or have a small team. But, if programming is your company’s living, you’ll need more.
It’s difficult to compare GitHub and GitLab’s pricing. It’s apples and oranges. I suggest starting with their free plans to get an idea of how your workflow operates on each platform and then look into subscribing to the one that works best for you.
The costs of subscriptions should be the least of your concerns. I’ve used both and, for my small-time programming purposes, they have worked extremely well.
That said, GitLab’s Premium plan costs $19 a month per user, while the full-featured Ultimate plan is $99 a month. As for GitHub, the Team plan is $40 a year per user and the Enterprise plan is $200 a year per user. But, the devil is the details, you may well find you’ll need to pay for extras no matter which service you finally subscribe to.
Don’t let price be your guide. What really matters is which one will give you the tools and services you need to develop your software to the best of your ability.