GitLab is an open-core DevSecOps platform that gives teams Git repository hosting, merge request code review, CI/CD pipelines, issue tracking, and wikis in one self-hostable application, aimed at organizations that want to run their development lifecycle on infrastructure they control.

What it is

GitLab is a Ruby on Rails application that manages Git repositories and the work that surrounds them. It combines repository hosting with fine grained access controls, merge requests for code review and collaboration, and continuous integration and continuous deployment pipelines that build, test, and deploy applications. Each project can also carry its own issue tracker, issue board, and wiki, so planning and documentation live beside the code. The project is open-core: most of the code is MIT, while the files under /ee are proprietary but source available and open to contributions.

The concrete thing it replaces is the assembly of separate tools that most teams otherwise stitch together. Instead of running a Git repository manager, a standalone code review tool, and a distinct continuous integration server that must be wired back into the repository, GitLab provides one application covering all of those roles. The README notes that GitLab CI is a continuous integration server that is easy to integrate with GitLab, which is the point: the pipelines, the review workflow, and the repositories share one permission model and one interface. This registry entry is a read-only mirror of GitLab Community Edition; all development happens in the canonical source hosted on GitLab.com.

Key capabilities

• Git repository management with fine grained access controls that keep code secure.
• Merge requests for code review and collaboration.
• CI/CD pipelines to build, test, and deploy applications.
• Per-project issue tracker, issue board, and wiki.
• Three editions: GitLab Community Edition (CE) under the MIT Expat license, GitLab Enterprise Edition (EE) with extra features aimed at organizations with more than 100 users, and JiHu Edition (JH) tailored for the Chinese market.
• Open-core licensing, with most code under MIT and /ee files proprietary but source available.
• Omnibus packages for Debian and RPM, installed through the system package manager.

Who uses it and how

• More than 100,000 organizations use GitLab, and the README describes it as the most popular solution for managing Git repositories on-premises.
• Organizations with more than 100 users typically move to Enterprise Edition and become subscribers to get official support alongside the extra features.
• Teams operating in the Chinese market use the JiHu Edition, which is tailored specifically for that region.
• Teams that do not want to run anything themselves use GitLab.com, where GitLab is available as a free hosted service.
• Contributors working on GitLab itself set up the GitLab Development Kit (GDK), rather than installing and configuring every dependency by hand.

Getting started

The recommended installation is the Omnibus packages available from the GitLab package server; select the operating system, download the Debian or RPM package, and install it with the system's package manager. For development on GitLab itself, use the GitLab Development Kit (GDK), or copy config/puma.example.development.rb to config/puma.rb if configuring dependencies manually.

How it compares

The facts provided name no comparable tools, so GitLab stands alone in this registry. Within the project itself the comparison is between editions rather than products: Community Edition is free under the MIT Expat license, while Enterprise Edition requires a subscription for extra features and official support. JiHu Edition is the third variant, tailored for the Chinese market.

When to use it — and when not to

Self-hosting means meeting the system requirements documented in doc/install/requirements.md and accepting operational responsibility for the application and its pipelines. Installing by hand rather than through Omnibus is explicitly described as slower and more error prone, and setting up a development environment without GDK means installing and configuring every dependency yourself, which the README calls a lot of work. The registry also lists the license as NOASSERTION even though the README explains the MIT plus proprietary /ee split, and this mirror is read-only, so issues and merge requests must go to the canonical project on GitLab.com instead.

cp config/puma.example.development.rb config/puma.rb