GitLab vs GitHub – A 2022 Comparison

Version Control Systems (VCS) have been at the forefront of the Dev*Ops revolution and leading that charge has been Git. Since its creation in 2005, Git has enjoyed a meteoric rise to become one of the most widely adopted version control systems worldwide.

Although many adoptions of Git are available today, two hosted solutions have become widely popular with developers and businesses alike – GitHub vs GitLab.

GitLab

In 2014 GitLab was founded and distributed under the MIT License. Over time the product has evolved both in product model as well as in philosophy, arriving at its current incarnation of a platform intended to serve the needs of DevOps teams end-to-end from the Software Development Lifecycle (SDLC) to project management. The platform approach is especially beneficial for teams who may not have in-house DevOps experts with free cycles to evaluate the myriad of tools available on the open marketplace and instead want a “just works” solution. The hidden cost of the GitLab philosophy is in the loss of freedom to choose and combine tools ad hoc – an exercise which is itself a hidden cost of GitHub. GitLab recently announced plans to go public via IPO – TechCrunch has delivered a terrific write-up of the launch.

GitLab estimated over 31 million developers in 2020 and a ⅔ share in the self-managed Git market. biterg.io also makes available a dashboard full of interesting live statistics.

Notable projects and customers of GitLab include Goldman Sachs, Ticketmaster, the Cloud Native Computing Foundation (CNCF), and more.

Related: What is GitLab?

GitHub

GitHub was the first Cloud-hosted Git solution, launching in 2008 and setting the standard for such solutions; one notable exception being SourceForge which was founded in 1999. As Cloud-focused services, including GitHub, gained in popularity, more businesses moved to adopt the model and looked to leaders such as GitHub for support. In 2018 GitHub was acquired by Microsoft as both a tactical move – Microsoft had come to depend on GitHub services for many of its codebases – and strategic – as part of a larger emphasis by Microsoft on Cloud solutions. Taking a more self-managed approach, the GitHub platform supports a wide range of community-developed solutions to provide for the DevOps lifecycle.

GitHub boasted 56 million developers authoring 1.9 billion updates in 2020 and 60 million new repositories created that year.

Notable projects and customers of GitLab include Procter & Gamble, Hashicorp, Autodesk, DataDog, Spotify, and more.

GitLab vs GitHub – Comparison

Because both vendors provide a Git solution, it should come as little surprise that they share a great deal in common and in fact may be indistinguishable for some organizations that require only a certain subset of features beyond the base version control system. In addition to their inherent similarities, GitLab and GitHub often release features that compete with the capabilities of the opposing platform, causing them to continuously merge and diverge in supported features.

Looking beyond the core Git services, GitLab and GitHub take a different view on the best way to provide value to their customers:

• GitLab endeavors to provide a full platform of services built to enhance the native features of Git and serve customers’ end-to-end needs, for example, a Google search for “gitlab ci/cd examples” returns several results including this page.
• GitHub focuses chiefly on Git activities directly with few integrated tools but a vibrant user ecosystem of 3rd party applications; a Google search for “github ci/cd examples” also returns the GitLab results without a mention of GitHub on the first page of results.

Flow

For some organizations adopting Git for the first time, without a supporting hosted service (like GitHub or GitLab), the workflow can be a significant challenge. Although there are many different ways to implement Git Flow, this diagram from nvie.com presents a common approach:

Both GitLab and GitHub aim to simplify this model with respective takes on flow:

• GitLab Flow suggests a few different example scenarios from the Production branch to a more general per-environment branch to a release-focused approach. Each of these is designed to account for the wide variety of business needs and DevOps maturity encountered.
• GitHub Flow recommends a feature-driven branching approach where all changes are merged into a single main branch and then deployed. This workflow, much simplified from the original Git Flow, depends on businesses being able to always perform a deployment from a single branch – a pattern common in Software as a Service (SaaS) projects – which may not fit all business needs.

Although GitLab and GitHub may prescribe some different approaches to flow management since both products implement Git-based solutions any strategy can easily be ported to both platforms as needed by a team or business.

Self-Hosted

Although both solutions were and remain primarily Software as a Service (SaaS), some organizations may need to self-host Git for regulatory, security, or workflow reasons. Both GitLab and GitHub offer this capability, with the latter requiring an Enterprise organization account which comes at a cost.

Private Repositories

Sharing data is one of the central goals of Git, but sharing with the world may not align with the goals of every organization and so both GitLab and GitHub support private repositories – such as available by invite-only. The number of private repositories is unlimited in both cases, but each limits the number of collaborators that are permitted for free, raising the limit based on paid tier thereafter.

Continuous Integration and Continuous Deployment

Both GitLab and GitHub recognize the importance and value of CI/CD as related to the SDLC and DevOps culture, however, each takes a different approach as to how to best support these efforts. GitLab’s platform concept includes options for many tools such as pipelines and runners. GitHub includes actions – similar to GitLab runners – but other operations, such as continuous deployment, are left to 3rd party and community projects to support.

Documentation & Wiki

Both GitLab and GitHub recognize the importance of documentation and communication as foundational capabilities of healthy DevOps organizations. While inline documentation, such as Git Readme files, is included natively only GitLab includes wiki support for free.

Issue Tracking

Inherent to a DevOps culture is the ability to actively manage, report on, and participate in the life cycle of changes; and one important category of changes is ‘issues’. In the GitLab / GitHub universe, an issue is not specifically a defect but can represent all manner of discussion about a software project tied to a repository. Discussion can range from defects to feature requests to version releases to a form of help forum. Importantly, issues can be tied to specific branches, or even lines of code within an associated repository, allowing for highly targeted focus as well as clear insight into the future plans of the project.

Security Assertion Markup Language (SAML) Single Sign-On (SSO)

Some projects – such as the Linux kernel – are public and any developer may submit a contribution to be considered; in this scenario a developer is authenticated by the provider – GitHub for the Linux kernel. Some organizations have more strict requirements for authentication and authorization that necessitate external workflows – such as integrating with a corporate identity product or centralized authentication gateway. GitLab includes SSO integration but GitHub requires an Enterprise organization (GitHub’s term for the highest paid tier of service).

Value Stream Management

Value Stream Management (VSM) is an important emerging lean business practice discussed in a previous article. While the GitHub ecosystem does have projects and tools to implement VSM, GitLab has integrated the practice into their platform directly as Value Stream Analytics.

Security and Compliance Tools

As already discussed above, both GitLab and GitHub provide robust security frameworks and compliance documentation. The table below compares the different features in this domain on both platforms.

GitLab vs GitHub – Comparison Table

* Although private repositories are included, the number of collaborators differs by pricing and provider

Alternatives

While GitLab and GitHub capture a combined significant portion of the Git marketplace, there are several alternatives available:

Bitbucket (link)

As a part of the Atlassian suite of products, Bitbucket shares many features with both GitLab and GitHub, including a self-hosted option. Thanks to the Atlassian ecosystem, Bitbucket is able to leverage capabilities from Jira, Bamboo, Opsgenie, Statuspage, and more to support the full DevOps life cycle.

SourceForge (link)

The SourceForge Git service supports the full range of Git functionality as well as webhooks to integrate ad hoc services on both sides of Git events. On their About page SourceForge reports “With the tools we provide, developers on SourceForge create powerful software in over 502,000 projects; we host millions of registered users. Our popular directory connects nearly 30 million monthly users with all of these open-source projects and serves more than 2.6 million downloads a day. Our business software directory lists over 72,400 software titles.”

Cloud (GCP Cloud Source Repositories / AWS CodeCommit / Azure Repos)

Public Cloud solutions support Git operations but primarily the value of these products comes from the global scale and resilience of their providers combined with the close integration to other services in the respective Cloud ecosystems. For example, the ability to automatically launch Cloud resources in response to code changes can provide significant value to organizations.

Gogs (link)

Gogs is an open-source Git server written in Golang and designed to be a simple and stable way to self-host a Git service (ironically the project is hosted on GitHub). In addition to common Git capabilities, Gogs supports organization webhooks, including Slack, Discord, and DingTalk.

Conclusion

After all, is said and done, there’s still one big question – GitLab vs GitHub, which should I choose? Considering a few criteria may help to answer:

Capabilities

Because both GitLab and GitHub implement a Git server, if Git is the right solution for your team or organization then either vendor can be expected to be a good fit. While core Git capabilities are wrapped by graphical interfaces from each vendor, the rise of Visual Studio Code as a development environment adds complexity to the developer experience discussion – such as whether code reviews should take place in a Git web interface or directly in an IDE.

Cost

Being Cloud services, both GitLab and GitHub structure cost above account subscription as a factor of usage, which will be the primary driver in cost differences between the two. For example, when considering the cost of Runners or Actions as a part of a CI/CD pipeline the plans break out as 400 / 10,000 / 50,000 and 2,000 / 3,000 / 50,000 minutes per month included by GitLab and GitHub respectively. While overages incur additional costs, small incremental costs for automation may offset the additional cost of the next tier of service; this must be calculated and carefully modeled by teams individually. Exempted from these numbers are self-hosted resources which are free for both providers but include their own inherent costs.

Features

While features will most likely be a determining factor in choosing a hosted Git solution, the ongoing arms race between GitLab and GitHub ensures that a feature comparison of the vendors is at best a temporary view. Examples of features that some teams find match business requirements include:

• Analytics
• Issue Tracking
• Collaboration
• Self-hosted

Philosophy

For some teams, the GitLab platform approach can be a significant performance enabler by being opinionated on tools and approaches while providing an included implementation of those opinions. For other teams, the GitHub community approach – relying on contributed tools and services to support various capabilities – can help to drive performance by ensuring that organizations can meet all requirements from security to tools integration to process standards and more. It’s very likely that an organization fits into only one of these categories, making this a key differentiator for selecting a vendor.