Project113

Example: Branch Protection Model

Set up a production-grade branch protection model where only authorized maintainers can merge to master, force pushes are blocked, and all changes require reviews.

Goal

  • Protect the master branch from force pushes.
  • Require at least one approval from a maintainer before merging.
  • Allow developers to push to feature branches freely.
  • Protect release/% branches with stricter rules.

Step 1: Create Roles

Create two custom roles in your repository settings:

  • developer — Can read, push to feature branches, and create change requests.
  • maintainer — Can read, push, merge change requests, and manage settings.

Step 2: Add Members

Add your team members to the repository and assign them the developer role. Assign the maintainer role to senior engineers or team leads.

Step 3: Create Ref Policies for Master

Each ref policy applies its permissions to a single subject set (members, roles, groups, or audiences), so protecting master requires two policies:

Policy 1 — Block force pushes:

  • Name: "Block force pushes on master"
  • Pattern: master
  • Ref type: heads
  • Priority: 10 (high)
  • Deny: git.ref.force_push
  • Subjects: Members

Policy 2 — Restrict merges to maintainers:

  • Name: "Maintainers merge master"
  • Pattern: master
  • Ref type: heads
  • Priority: 10 (high)
  • Allow: git.ref.merge
  • Subjects: role maintainer

Step 4: Create Ref Policies for Releases

Protect release/% branches the same way, again using two policies:

Policy 1 — Block force pushes:

  • Name: "Block force pushes on releases"
  • Pattern: release/%
  • Ref type: heads
  • Priority: 5 (medium)
  • Deny: git.ref.force_push
  • Subjects: Members

Policy 2 — Restrict merges to maintainers:

  • Name: "Maintainers merge releases"
  • Pattern: release/%
  • Ref type: heads
  • Priority: 5 (medium)
  • Allow: git.ref.merge
  • Subjects: role maintainer

Step 5: Set Repository Defaults

In repository settings, configure these defaults for all change requests:

  • Require CI to pass: Yes
  • Minimum approvals: 1
  • Require all threads resolved: Yes
  • Auto-delete source branch: Yes

Result

With this setup:

  • Developers can create feature branches and push freely.
  • When they open a change request to merge into master, they need at least one maintainer approval and passing CI.
  • Force pushes to master and release/% branches are blocked.
  • Only maintainers can merge to protected branches.