System requirementsMinimum hardware requirements: 4 vCPU and 4 GB RAM support up to 500 users. No specific recommendation for disk size.Supporting up to 3000 users, requires 8 vCPUs, 48 GB RAM, 300 GB attached storage, 200 GB root storage.GitLab (fewer requirements)
GitLab installs on most standard Linux distributions. GitLab has a number of installation methods, the most popular being “Omnibus” installation on Linux, Helm charts for installation on K8S and Docker installation. Installing GitLab using the Docker installation, server provisioning and Gitlab installation took about 2.5 hours.
On GCP, it provides a set of gcloud compute commands, which provision all needed resources and install GitHub. The whole installation process took about 2.5 hours.
All configuration is done by editing the GitLab configuration file (gitlab.rb) and running reconfigure.
All configuration is done using GitHub admin web interface (“Management Console”) and clicking Save changes.
Similar. GitHub is more user-friendly as it does not require familiarity with Linux shell. On the other hand, GitHub’s Save Changes takes a very long time, about 10 min, while GitLab’s reconfigure is stored as-code and takes about a minute.
GitLab backup is a command-line utility, which runs on the same Linux server as GitLab. It can be configured to run at regular intervals as a cron job. There are also alternative GitLab backup methods like file system snapshot and GitLab Geo (Premium and Ultimate)
GitHub Enterprise Server Backup Utilities is a backup system installed on a separate host. It takes backup snapshots of the GitHub Enterprise Server instance at regular intervals over a secure SSH network connection. Use a snapshot to restore an existing GitHub Enterprise Server instance to a previous state from the backup host.
GitLab (does not require a dedicated backup host)
Maintenance Mode
GitLab has a maintenance mode, which blocks all external actions that change its internal state. There are three ways to enable maintenance mode: web UI, API and Rails console.
GitHub has a maintenance mode, takes the GitHub Enterprise Server instance offline and users can’t access it. Use the Management Console.
GitLab (maintenance mode allows read access)
For single node installations, GitLab is not available to users while an upgrade is in progress. For multi-node installations, there is a possibility to perform zero downtime upgrades.
There are two types of GHES upgrades, hotpatch and feature release. A hotpatch does not require a maintenance window and usually does not require a reboot, It can be installed using the Management Console or an administrative shell utility. A feature upgrade does require a maintenance window and can be installed only using the administrative shell utility.
GitLab, with better support for zero-downtime upgrades
Architecture and Scalability
Gitlab is a modular application, built of a number of components like GitLab Workhorse, Nginx, Redis, Gitaly, PostgreSQL, etc. In the basic configuration the components can all exist in a single node, but to scale, they can be distributed to separate nodes. One or more nodes can be dedicated to the same component (e.g., two or more Gitaly storage servers). To install a single component on a node, install the same Omnibus image and then activate only that component by editing the Gitlab configuration file (gitlab.rb). Horizontal scaling is supported for App Server nodes without downtime. It could be configured in an automatic way like the example for HA installation of GitLab on AWS.
GHES is a monolith, which cannot be split into a number of components. The only way to scale it is to move to a bigger server (vertical scaling requiring downtime).
GitLab, as it allows horizontal scaling
High Availability
GitLab high availability is achieved by having full redundancy of all components and automatic failover (i.e. if a component fails, its counterpart automatically takes over). The parts include: • Omnibus installation with database redundancy and automatic failover (PostgreSQL and Redis) failover (Premium).
There is no truly HA configuration of GitHub.
GitLab (has true HA)
Disaster Recovery
GitLab Geo (Premium) allows replication of a GitLab instance to other geographical locations as a read-only fully operational instance that can also be promoted in case of disaster.
GHES has a configuration, in which a fully redundant secondary GitHub Enterprise Server appliance is kept in sync with the primary appliance through replication of all major datastores. GitHub calls this configuration HA, but since the failover is manual, it's defined here as a DR.
GitLab proposes more workflow models than GitHub, with feature, development, production, environment and release branches. GitLab Flow is the standard. GitLab workflow is supported by merge requests (MRs), which are a framework for code review before merging.
GitHub proposes a simple workflow, which has feature branches and a main branch. GitHub workflow is supported by pull requests (PRs), which are essentially the same as GitLab MRs.
Similar (because any workflow works on both systems)
Issue Tracking
GitLab Issues is an issue tracking system, seamlessly integrated with commits and Merge Requests. There is a limited number of fields and statuses, but some of the missing functionality is achieved by using labels, in particular scoped labels (Premium), which can stand in for list-of-values fields and statuses. GitLab also has Epics (Premium), which are similar to Issues, but sharing a theme across several projects and milestones. An Epic can be a parent of one or more child Epics and of one or more Issues
There is a limited number of fields and statuses, and there is no feature similar to GitLab’s scoped labels. However, there is a beta program, which promises many new features, like custom fields and custom flows.
In GitLab, developers can use groups to manage one or more related projects at the same time. One can use groups to manage permissions for his projects. If someone has access to the group, they get access to all the projects in the group. GitLab also supports up to 20 levels of subgroups, which is useful for large organizations or large applications.
However, organizations can’t be used for giving access to projects. For example, being a member of an organization is not enough for being able to pull and push from that organization’s repos (see here) There is no feature similar to GitLab’s subgroups (there are no “sub-organizations”).
GitLab (groups and subgroups are much more useful than GitHub’s organizations)
CI/CD - Setup
In GitLab, a user has to generate an access token, provision a runner server, install runner software on it and register it vis-a-vis GitLab using the token. There are a number of executors, like shell, Docker, Kubernetes. Runner installation on K8S is supported by GitLab’s web UI. In particular one can create a cluster on Amazon EKS or Google GKE and install a runner on it, all from the GitLab’s web UI.
To enable GitHub Actions on GHES, one must have access to external blob storage. Only Azure Blob storage, AWS S3 or S3-compatible MinIO Gateway for NAS are suitable. GCP storage won't work. Runner setup is a little simpler than in GitLab: all setup commands are provided on an instance/organization/project’s page (depending on the runner’s scope) and the access token is generated automatically. There is third-party software which run GitHub Actions on K8S (e.g. here).
CI/CD - Basic Pipeline Configuration
In GitLab, a CI/CD pipeline is configured using a YAML file. A GitLab pipeline’s major building blocks are stages and jobs. A stage consists of jobs, which run in parallel. Stages are executed sequentially: if all jobs in a stage succeed, the pipeline moves on to the next stage. Recently (14.2), GitLab also introduced stageless pipelines, which use the same needs keyword as GitHub. A developer can use the extends keyword to reuse configuration sections.
In GitHub uses the term "workflow" instead of “pipeline”. A workflow is also configured using a YAML file, with syntax quite similar to that of GitLab. In GitHub, there are no stages, but a similar functionality is achieved using the needs keyword. Because of the lack of extends, users need to cut and paste code, making their configuration files longer and less maintainable. GitHub Actions can be triggered on non-code events, such as creation of new issues.
GitLab (because of the ability to re-run a single job) but also GitHub (because of ability to trigger on other events)
CI/CD - Advanced Features (major differences)
GitLab Auto DevOps recognizes the code and automatically sets up the end to end template. Preview App before merge to reduce defects, shorten development time. Multi-project pipelines - Set up GitLab CI/CD across multiple projects, so that a pipeline in one project can trigger a pipeline in another project. Visualize the entire pipeline in one place, including all cross-project interdependencies. Parent-Child pipelines, which can run concurrently and save pipeline run times. Merge trains (Premium) to keep the target branch green. In GitLab, it's possible to place the CI/CD configuration file outside the repository, and thus use the same configuration file for a number of projects.
Workflow templates for a variety of languages and tooling. When setting up workflows in a repository, GitHub analyzes the code in the repository and recommends workflows based on the language and framework in the repository. However, there is no feature similar to GitLab’s Auto DevOps. There is a third-party Github Action Build Chain. It is a tool for GitHub actions to build multiple projects from different repositories in a single action. In GitHub, there is no parent-child workflow feature, resulting in longer pipeline run times. In GitHub, workflow configuration files must be stored in the .github/workflows directory of the repository. If multiple projects using the same build procedure, there need to be multiple copies of the workflow file.
Container Scanning
Container Scanning - Scan Docker containers for known vulnerabilities
DAST API - Analyze running web APIs for known vulnerabilities.
API Fuzzing
API fuzzing - Find unknown bugs and vulnerabilities in web APIs with fuzzing.
Secret Detection
Secret Detection - Analyze Git history for leaked secrets.
Secret scanning - Detect secrets, for example keys and tokens, that have been checked into the repository. Part of GitHub Advanced Security
Static Application Security Testing (SAST) - Analyze source code for known vulnerabilities.
Code scanning - Search for potential security vulnerabilities and coding errors in code. Set up code scanning to use the CodeQL product maintained by GitHub or a third-party code scanning tool. Part of GitHub Advanced Security.
IAC Scanning
Infrastructure as Code (IaC) Scanning - Analyze IaC configuration files for known vulnerabilities.
Coverage fuzzing
Coverage fuzzing - Find unknown bugs and vulnerabilities with coverage-guided fuzzing
Cluster image scanning
Cluster Image Scanning - Scan Kubernetes clusters for known vulnerabilities
License compliance
License Compliance - Search a project’s dependencies for licenses that are not compliant with the project's policy.
Security Dashboard
Security Dashboard - View vulnerabilities in an individual project or across a group.
Dependency review - Show the full impact of changes to dependencies and see details of any vulnerable versions before merging a pull request.
GitLab has a full dashboard; GitHub’s capability is limited
Integrations with Third Parties
GitLab has about 30 integrations with 3rd party tools. Some integrations (e.g., Elasticsearch and Jira) are set up on the instance level, while some (e.g. Jenkins) are set up on project level. All integrations are variable for all tiers, except for the Elasticsearch and GitHub integrations (Premium). All GitLab integrations are part of the GitLab installation, are documented and supported by GitLab.
GitHub has a Marketplace of third party tools. These tools are divided into apps and actions. Apps on GitHub allow to automation and workflow improvement. E.g., GitHub integration with Jira. Apps are set up on organization level. Currently there are 493 apps in the GitHub marketplace. Actions are individual tasks that can be combine to create jobs and customize workflows. E.g., Close Stale Issues, which warns and then closes issues and PRs that have had no activity for a specified amount of time. Actions are set up on repository level. Currently there are 10857 actions in the GitHub marketplace.
Similar but different. GitHub’s Marketplace provides more capabilities. On the other hand, GitHub integrations require more maintenance, because they are not part of the GitHub installation, are not supported by GitHub and must be upgraded separately
Integrations with K8S - Application Installation
Install a GitLab server on K8S using Helm Chart/GitLab Operator.
There is no option of installing GHES on K8S.
Integrations with K8S - CI/CD
Install GitLab runner on K8S using Helm Chart/GitLab Operator. Integrate GitLab with K8S for application deployment using Kubernetes Agent Server (KAS). Auto DevOps including auto deployment and auto monitoring Manage cluster applications using KAS.
Deploy to Google Kubernetes Engine - Deploy to Google Kubernetes Engine as part of continuous deployment (CD) workflows. Red Hat GitHub Actions - Red Hat has released a series of GitHub Actions to ease integrating Red Hat OpenShift with GitHub’s Actions. (Third party) Open source actions-runner-controller - Kubernetes controller for GitHub Actions self-hosted runners. (Third party)
Caching - A cache is one or more files that a job downloads and saves. Subsequent jobs that use the same cache don’t have to download the files again, so they execute more quickly
Caching - Similarly to GitLab, create and use caches for dependencies and other commonly reused files.
GitLab Artifacts - Jobs can output an archive of files and directories. This output is known as a job artifact. To share data between jobs: • Creating artifacts - To create job artifacts, use the artifacts keyword in the .gitlab-ci.yml file. • Using artifacts - By default, jobs in later stages automatically download all the artifacts created by jobs in earlier stages. Control artifact download behavior in jobs with dependencies. Artifact Storage - By default, GitLab uses the local disk where GitLab is installed to store the artifacts. Alternatively, use an object storage like AWS S3. Downloading Artifacts - Download artifacts both by using the web UI or the REST API.
GitHub Artifacts allow sharing of data between jobs in a workflow and store data once that workflow has completed. To share data between jobs: • Creating artifacts - Give the uploaded file a name and upload the data (using the actions/upload-artifact action) before the job ends. • Using artifacts - It is only possible to download artifacts (using the actions/download-artifact action) that were uploaded during the same workflow run. Artifact Storage - In GHES, artifacts are stored in the external blob storage.
GLab is a third party open source Gitlab CLI tool written in Go (golang) to help work seamlessly with Gitlab from the command line. Work with issues, merge requests, watch running pipelines directly from the CLI among other features. Core Commands • glab mr [list, create, close, reopen, delete, ...] • glab issue [list, create, close, reopen, delete, ...] • glab pipeline [list, delete, ci status, ci view, ...] • glab release • glab repo • glab label • glab alias GLab can be installed on MacOS, Linux and Windows.
gh, GitHub CLI, is an open source tool for using GitHub from a local computer's command line. • View, create, clone, and fork repositories • Review, diff, and merge pull requests • Run, view, and list workflows • Create, list, view, and delete releases • Create, edit, list, view, and delete gists • List, create, delete, and connect to a codespace Use GitHub CLI in GitHub Actions workflows. For example, use the gh issue comment subcommand to add a comment when an issue is opened.
The functionality looks similar. The major difference is that gh is the official supported tool of GitHub, while GLab is a 3rd-party tool.
Desktop Application
GitDock is a MacOS/Windows/Linux app that displays all GitLab activities in one place. Instead of the GitLab typical projector group-centric approach, it collects all the information from a user-centric perspective. It’s very much an MVC and not yet a fully supported GitLab product.
In addition to standard Git actions, starting some GitHub actions, like creating an issue and opening a pull request.
There's no significant advantage over other Git GUIs like Sourcetree.
Cloud-based Environments
GitPod is a paid service, which spins up pre-configured, standardized dev environments from any git context when needed them and closes them when done. Runs VS Code and any JetBrains IDE. GitPod monitors changes in the Git repository and prepares dev environments with every change. That preparation not only includes setting up the tools and checking for the right git branch, but perhaps more importantly, compiling the code, downloading all dependencies, and initializing everything else needed by the developer to become productive. When the developer is ready to start working, he/she gets a fresh, ready-to-code dev environment within seconds. GitPod can be also self-hosted on GKE, EKS, AKS and K3s. GitPod works with GitLab, GitHub and BitBucket,
GitHub Codespaces is a paid service that provides developers with on-demand access to a secure development environment running a given codebase (Git repository) on a remote server. It also allows the developer to debug, maintain and make changes via a full-featured (with syntax highlighting, themes, extensions, version control, etc.) browser-based or locally installed Visual Studio Code IDE from their local machine.
GitHub (CodeSpaces configuration is powerful)
IDE Integrations
GitLab Workflow - GitLab VS Code extension - It helps view issues, create and review merge requests, validate GitLab CI configuration, view the status of a pipeline, create and paste snippets to, and from, the editor. It is maintained by GitLab. CodeStream’s GitLab integration for IntelliJ IDEA, WebStorm, PyCharm, and all other JetBrains IDEs - The integration, which works with both GitLab Cloud and GitLab Self-Managed, lets developers create, review, and merge GitLab merge requests without ever leaving the JetBrains editor, all with full source-tree and full file access, keybindings, and all the code intelligence embedded in the development environment.
GitHub Pull Requests and Issues for VS Code - This extension allows reviewing and managing GitHub pull requests and issues in Visual Studio Code. Sublime-github for Sublime Text - Provides a number of useful commands for GitHub, including creating and browsing Gists (code snippets), opening and editing files on GitHub, and bringing up the blame and commit history views Intellij - Provides integration out of the box. Create or clone projects, open the version of a file directly in GitHub (i.e if working on a particular file and need to check against the original GitHub version, do it with a few clicks) a even create new Gists directly from the IDE.
AI Pair programming
Still under consideration
GitHub Copilot is an AI pair programmer. GitHub Copilot is powered by a new AI system developed by OpenAI Codex and is coming soon to Visual Studio Code. It aims to help Programmers code faster. It basically draws context from the code itself, suggesting whole lines or entire functions. The GitHub Copilot editor extension sends comments and code to the GitHub Copilot service, which then uses OpenAI Codex to synthesize and suggest code. It actually works by reading through all the open-source code on the GitHub repos worldwide and then collecting the data and trying to find the best possible code related to it. For now, GitHub Copilot will only be made available to use in Visual Studio Code and the access is limited to a small group of testers. The preview version is available for free.
Code Navigation
Possible to integrate with SourceGraph on GitLab.com for code navigation.
Programming language-aware code navigation allows developers to jump directly to definitions and references for specific identifiers.
Code Search
Search within code, as well as issues etc. using GitLab Advanced Search.
New Code Search feature set includes advanced syntax for finding content within code and links directly to the Code Navigation features.