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.ymlneeds rules/workflow targetingmerge_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
- Immutable releases - GitHub Docs
- Immutable releases are now generally available - GitHub Changelog
- Releases now support immutability in public preview - GitHub Changelog
- Immutable container tags - GitLab Docs
- Merge requests - GitLab Docs
- Protected branches - GitLab Docs
- Branch rules - GitLab Docs
- Merge request approval policies - GitLab Docs
- Merge request pipelines - GitLab Docs
- CI/CD pipelines - GitLab Docs
- CI/CD variables - GitLab Docs
- Deployment safety - GitLab Docs
- Deployment approvals - GitLab Docs
- Experimenting with Approval Bypass (and more) in GitLab