Enforcing Branch Protection and Approval Rules in GitLab

A shared repository without guardrails is an accident waiting to happen. Direct pushes to main, a single junior dev accidentally approving their own merge request, a hotfix that skips CI — you've either seen it, or you're about to. GitLab's branch protection and approval rules are the enforcement layer that makes your workflow auditable, consistent, and safe at scale.

Most teams implement some version of code review policy in their team norms or wikis. The problem is that norms are optional. GitLab's protected branches and approval rules are enforced at the platform level — they can't be bypassed by a distracted dev in a rush, and they produce an audit trail by default.

Prerequisites

Before configuring anything, make sure you have:

Part 1: Protected Branches

A protected branch controls who can push, merge, and force-push to that branch. GitLab applies this at the Git protocol level — even if someone has write access to the repo, protection rules can block specific operations.

Enabling Branch Protection via UI

Navigate to your project and go to Settings → Repository → Protected branches. You'll see a form at the top and a list of any existing protected branches below.

Configuring via API

If you manage multiple projects or want this in an IaC/automation workflow, use the GitLab REST API:

bash# Protect the 'main' branch — no direct pushes, merge by Maintainers only
curl --request POST \
  --header "PRIVATE-TOKEN: <your_token>" \
  --header "Content-Type: application/json" \
  --data '{
    "name": "main",
    "push_access_level": 0,
    "merge_access_level": 40,
    "allow_force_push": false
  }' \
  "https://gitlab.example.com/api/v4/projects/<project_id>/protected_branches"

Access level codes: 0 = No one, 30 = Developers + Maintainers, 40 = Maintainers, 60 = Admins.

Access Level Reference

Part 2: Merge Request Approval Rules

Approval rules define who must approve a merge request before it can be merged. They're separate from branch protection (which controls the merge action itself) — think of approvals as the required signoff step.

Setting Up Approval Rules via UI

Go to Settings → Merge requests → Merge request approvals. You'll find two sections: project-level rules that apply to all MRs, and options to allow individual MRs to add their own rules.

Key Approval Settings to Lock Down

Just below the rule list, you'll find several checkboxes that are easy to overlook but critical for a secure workflow:

Multiple Approval Rules (Premium+)

On Premium and Ultimate tiers, you can add multiple named rules with different approver groups. This is useful when you need cross-functional sign-off:

yaml# Example: two approval rules for a security-sensitive service
rules:
  - name: Backend Review
    approvals_required: 1
    approvers:
      - group: backend-engineers

  - name: Security Signoff
    approvals_required: 1
    approvers:
      - group: security-team

Both rules must be satisfied before the MR can merge. This is how you enforce, for example, that every database migration needs both a backend engineer and a DBA to approve.

Part 3: Code Owner Approvals

Code Owners let you tie approvals to specific files or directories — so changes to /infra require the platform team, and changes to /payments require the payments squad, automatically.

Setting Up a CODEOWNERS File

Create a CODEOWNERS file at the root of your repo (or in .gitlab/). The syntax follows .gitignore patterns:

CODEOWNERS# Default: all files require backend-team approval
*                          @backend-team

# Infrastructure changes require platform team
/infra/                    @platform-engineers

# Payment code requires both payments squad and security
/src/payments/             @payments-squad @security-team

# Frontend files require frontend team
*.tsx                      @frontend-engineers
*.css                      @frontend-engineers

# CI config requires DevOps sign-off
.gitlab-ci.yml             @devops-team

After committing the file, go to Settings → Repository → Protected branches and enable "Require approval from code owners" for your target branch. From that point on, any MR touching a file with a defined owner will automatically require approval from that owner before merging.

Part 4: Putting It All Together

Here's a recommended configuration matrix for common branch types in a real-world project:

Validating Your Configuration

After setup, always verify with a real test. Create a test branch, open a draft MR to main, and confirm that:

• Direct pushes to main are rejected at the Git level
• The author cannot approve their own MR
• Adding a new commit resets existing approvals
• The "Merge" button stays grayed out until all rules are satisfied

You can also audit all protected branch rules programmatically:

bash# List all protected branches for a project
curl --header "PRIVATE-TOKEN: <your_token>" \
  "https://gitlab.example.com/api/v4/projects/<project_id>/protected_branches"