Branch Protection + Rulesets

Story

Building-a-house world — same site and crew as every Phase 0 lesson.

In your city, buildings have to follow a building code. Before any new wall, wire, or pipe joins the real house, the inspector must have signed off, the automatic inspection rig must have run clean, and only a licensed worker can have done the job. These aren't rules anyone can wave away — they're baked into the gate. An eager worker can't skip them because they're in a hurry. Even you, the owner, can configure the gate to hold you to the same standard.

Branch protection rules and rulesets are GitHub's building code for main. Work can't join the real house unless the gate says it's allowed.

Branch protection rules

A branch protection rule attaches conditions to a single branch. The docs: it defines "whether collaborators can delete or force push to the branch and set requirements for any pushes to the branch, such as passing status checks or a linear commit history."

source: docs.github.com — About protected branches · fetched 2026-05-29

The key settings — and what each one blocks

Think of each setting as a clause in the building code. The gate won't open unless every turned-on clause is satisfied.

Rulesets — the newer, more flexible way

A ruleset is "a named list of rules that applies to a repository or to multiple repositories in an organization." It enforces the same protection settings as above, and adds:

source: docs.github.com — About rulesets · fetched 2026-05-29

• Named and togglable. Each ruleset has a name and a status: active ("will be enforced upon creation") or disabled ("will not be enforced"). Toggle it off for an emergency window; the config stays intact when you re-enable it.
• Pattern targeting. Apply to many branches or tags at once using fnmatch patterns — e.g. release/**/* catches every release branch in one rule.
• Stack and aggregate. "If multiple rulesets target the same branch or tag… the rules in each of these rulesets are aggregated," and "the most restrictive version of the rule applies." Two rulesets requiring 1 and 2 reviews respectively → 2 reviews required.
• Bypass list. Specific roles, teams, or GitHub Apps can be explicitly exempted.
• Visible to all readers. "Anyone with read access to a repository can view the active rulesets." Workers can see what rules are in play — no guessing.
• Organization-wide (Enterprise). One ruleset can enforce the same building code across every repo in an org — one policy, many sites.

Branch protection vs. rulesets — one-look contrast

Same goal: protect main with required reviews and CI checks, plus protect release/* with a stricter 2-review rule.

With classic branch protection:

Rule 1: branch = "main"
  ✓ Require 1 approving review
  ✓ Require status checks

Rule 2: branch = "release/*"
  ✓ Require 1 approving review    ← can't easily add a 2-review rule on
  ✓ Require status checks            the same pattern without replacing it

With rulesets:

Ruleset A: "Core safety"  [active]
  → targets: main, release/**/*
  ✓ Require 1 approving review
  ✓ Require status checks

Ruleset B: "Release extra gate"  [active]
  → targets: release/**/*
  ✓ Require 2 approving reviews

Result on release/*:
  Most restrictive wins → 2 reviews required.
  Toggle Ruleset B to [disabled] for an emergency hotfix.
  main still gets 1 review (only Ruleset A applies there).

How to get there (UI teaser)

You won't be clicking through this on the exam, but knowing the path helps:

• Classic branch protection: Repo → Settings → Branches → Add branch protection rule
• Rulesets: Repo → Settings → Rules → Rulesets → New ruleset

Both live under the Rules section in modern GitHub repos. Rulesets is the direction GitHub is actively developing — expect it to be what future exam questions reference.

Why this matters for GH-600

This is the enforcement layer behind "agents propose, humans and policy accept." Branches + PRs (0.3 / 0.4) let an agent propose work. Branch protection / rulesets are the gate that accepts or rejects — automatically, without anyone having to remember to check.

Trace it through: an AI agent finishes work on a branch and opens a PR to main.

• Require pull request reviews → the agent cannot merge without a human approving.
• Require status checks → the agent's PR can't merge until Actions tests go green.
• Restrict who can push + Block force pushes → the agent can't bypass the PR gate by pushing directly, and can't quietly rewrite main's history.

The building code doesn't care how fast or clever the agent is. The gate doesn't open.

When the exam asks "how do you prevent an autonomous agent from shipping unreviewed code to production?" — the answer is branch protection / rulesets requiring PR review + passing checks before merge.

Check-in — three questions

Open-ended. Think first, then peek at the suggested answer.

1. You want no code to reach main without a passing CI run AND a human sign-off. Which two branch protection settings do you turn on, and what does each one block?

   Suggested answer

   Require status checks — blocks merging until Actions (or other CI) checks report successful, skipped, or neutral. Failing checks = gate stays closed. Require pull request reviews — blocks merging until the required number of humans have approved the PR. Together: the agent's work physically cannot land on main without both a green CI run and a human sign-off.

2. Your team has a main branch and a family of release/v* branches. You want a 2-review rule on release branches and a 1-review rule on main. Can classic branch protection do this cleanly — and what's the ruleset alternative?

   Suggested answer

   Classic branch protection is awkward here: each rule targets one pattern, and you can't stack two rules on the same branch to get different review counts. With rulesets you create two named rulesets — "Core safety" targeting main with 1 review, and "Release gate" targeting release/**/* with 2 reviews. They stack: release/* gets the stricter of the two (2 reviews). Toggle "Release gate" to disabled for an emergency; it stays configured for when you re-enable it.

3. An AI agent opens a PR to main. Your building code: "Require PR reviews" + "Require status checks" + "Block force pushes" all on. Walk through what the agent can and can't do.

   Suggested answer

   The agent can open the PR and trigger the CI checks. It cannot merge: the gate stays closed until a human approves AND Actions reports a passing status. It also cannot push directly to main (all changes must go via PR) and cannot force-push to overwrite history. The building code holds regardless of who — or what — is pushing.

Mentor marks this lesson verified after you compare answers and say "got it" in chat.