GitHub Settings, Explained for GitLab: Branch Protection, CI/CD, and Secrets Management

Introduction

If you're migrating from GitHub to GitLab, or running both in parallel, you've probably hit the "wait, what's the GitLab equivalent of this GitHub setting?" moment more than once.

The tricky part is that GitHub often expresses a control as a single toggle, while GitLab tends to build the same control out of a combination of features — Protected branches, Merge request approvals, CI/CD variables, and Protected environments, among others.

This post walks through common GitHub settings and maps them to the closest GitLab equivalents. The goal isn't a strict 1:1 mapping — it's understanding how to assemble an equivalent control in GitLab.

Mapping Table

Release & Branch Settings

GitHub Setting	GitLab Equivalent	How to Configure	Notes
Enable release immutability	No identically-named toggle in GitLab. The closest control is Protected tags, restricting who can create the tags that releases are cut from	Decide on a tagging convention for releases (e.g. `v*`) and set up Protected tags for that pattern	See the warning below
Automatically delete head branches	Automatic deletion of the source branch after an MR merges	Enable the default behavior under Settings > Merge requests (per-MR "Delete source branch" is also available)	In GitLab this is a setting applied at MR creation/merge time
Require a pull request before merging	Use Protected branches to block direct pushes and push changes through MRs instead	Under Settings > Repository > Branch rules, set `Allowed to push and merge` to `No one`, and restrict `Allowed to merge` as needed	This isn't a single toggle that matches GitHub's "require PR" 1:1 — it's a combination of Protected branches and MR workflow. If you don't explicitly restrict `Allowed to push and merge`, direct pushes aren't actually blocked

A note on Enable release immutability
GitHub's immutable releases cover the inability to change or delete release assets, the inability to move or delete the associated Git tag, and automatic generation of release attestations. GitLab's Protected tags are a related control, but not equivalent immutability. Also note that GitLab's immutable tags feature is for the Container Registry — a separate feature unrelated to Git repository releases.

Approvals & Pipelines

GitHub Setting	GitLab Equivalent	How to Configure	Notes
Required approvals	Merge request approvals + approval rules	From the branch rule detail view, configure Merge request approvals and Approval rules — approvers and required approval counts can be set per branch	This is about attaching approval rules to protected branches. For stronger controls, consider disallowing author self-approval and requiring re-approval after new commits
Require status checks to pass	Pipelines must succeed	Enable under Settings > Merge requests. Also enable the MR pipeline in `.gitlab-ci.yml` so the right jobs actually run on the MR	See the warning below

A note on Require status checks to pass
Pipelines must succeed also blocks MRs that have no pipeline at all. When both a branch pipeline and a merge request pipeline exist, the merge request pipeline is what's evaluated. To get the MR pipeline working, you need rules (or a workflow) like this in .gitlab-ci.yml:

rules:
  - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'

Rules defined only in an included file aren't sufficient on their own.

Supply Chain & Variables

GitHub Setting	GitLab Equivalent	How to Configure	Notes
Require actions to be pinned to a full-length commit SHA	Pin CI/CD component or include references to a commit SHA or a fixed version tag	This isn't a UI toggle — it's about how you write `.gitlab-ci.yml`. When referencing external CI config or components, avoid mutable references like `branch` or `latest` in favor of fixed references. Consider `include:integrity` as well	Same context as GitHub Actions' third-party action pinning — avoiding moving-target external references is the underlying principle in GitLab too
Variables	CI/CD variables	Add variables at the project/group/instance level under Settings > CI/CD > Variables. Configure Protect variable, Masked, Environment scope, and File type as needed	Use Environment scope if you need different values per environment
Secrets	For everyday use, the closest equivalent is Masked / Protected CI/CD variables. For stricter management, use a secrets manager or an external secret provider integration	For a simple setup, register secrets as variables with Masked and Protected enabled. For stricter separation, design an external secret provider integration	The purpose is similar to GitHub Secrets — injecting sensitive values from outside — but it's more accurate to think of GitLab variables and secrets management as separate concerns

Protected variables are only passed to pipelines running on protected branches / protected tags. Whether a Merge Request pipeline can access a protected resource is conditional. Masked is effective at suppressing exposure in logs, but it isn't a complete secrets-management solution on its own.

Environments & Deployment

GitHub Setting	GitLab Equivalent	How to Configure	Notes
Environment	A combination of Environments, environment-scoped variables, Protected environments, and Deployment approvals	Define `environment:` on the deploy job in `.gitlab-ci.yml`. Split values per environment using Environment scope under Settings > CI/CD > Variables. For controls like production, configure Allowed to deploy and approval rules under Settings > CI/CD > Protected environments	GitHub's "switching environment variables" and "production approval" are, in GitLab, a combination of multiple features rather than one (see the warning below too)
Require deployments to succeed before merging	No single 1:1 toggle. A combination of Pipelines must succeed, deploy/verify jobs, Protected environments, and Deployment approvals	Combine the Pipelines must succeed setting with Protected environments / Deployment approvals settings for the target environment	There's no feature that directly represents "successful deploy to a specific environment" as a merge condition the way GitHub does — GitLab achieves this through pipeline design plus environment protection
Production secrets protection	Protected variables + environment scope (+ protected runners as needed)	Set up production CI/CD variables as Protected, and restrict them to production using Environment scope	The basic design is to only expose production secrets to protected branch / protected tag pipelines. GitLab also recommends combining Protected variables with Protected environments for production secrets

A note on Deployment approvals
Approval doesn't trigger automatic execution — manual execution is still required after approval. If you're thinking of it the same way as GitHub's Environment protection rules, where "approval = deployment starts automatically," this is the point where things get stuck.

Practical Takeaways

Trying to map GitHub setting names directly 1:1 onto GitLab doesn't quite work. It's easier to think of GitLab in terms of these five combinable axes:

Branch protection (Protected branches)
MR approval (Merge request approvals)
Pipeline success (Pipelines must succeed)
Variable protection (Protected variables / Environment scope)
Environment protection (Protected environments / Deployment approvals)

From a supply-chain security standpoint, these three points are worth emphasizing:

Pin external CI config and components to a SHA or a fixed version
Separate production credentials using Protected variables + Environment scope
Govern production deployments with Protected environments + Deployment approvals

Summary of Caveats

Enable release immutability has no identically-named GitLab toggle. Protected tags are a related control, but don't guarantee the full immutability of release assets and associated Git tags the way GitHub's immutable releases do
GitHub's immutable releases automatically generate an attestation for the release artifact
With GitHub's immutable releases, even if you delete a repository and recreate it under the same name, a tag name already used by an immutable release can't be reused
GitHub's immutable releases only apply to releases created after the feature is enabled — existing releases remain mutable. Even after disabling the feature, releases that already became immutable stay immutable
GitLab's Pipelines must succeed also blocks MRs with no pipeline at all. When both a branch pipeline and a merge request pipeline exist, the merge request pipeline is what's evaluated
To rely on MR pipelines, .gitlab-ci.yml needs rules/workflow targeting merge_request_event — rules defined only in an included file aren't enough
Protected variables are only passed to pipelines on protected branches / protected tags. Whether a Merge Request pipeline can access a protected resource is conditional
Deployment approvals still require manual execution after approval — it isn't automatic

References