If two GitHub rulesets and a branch protection rule target main, which rules apply?

## The evaluation model When a push arrives or a merge is attempted, GitHub collects every policy that targets the ref in question: 1. Each **repository ruleset** whose `conditions` match the ref name, and whose enforcement is `active`. 2. Each **organization ruleset** whose conditions match both the repository (by name or repository property) and the ref, again if active. 3. The **classic branch protection rule** whose name pattern matches the branch, if one exists. All of their rules are then applied together. There is no precedence order in the sense of "the most specific one wins and the others are ignored" — that intuition, borrowed from CSS or firewall rules, is the single biggest source of confusion here. Where two sources state the same constraint with different strength, the outcome is the strictest reading: approvals take the highest required count; if any applicable source requires signed commits, signed commits are required; if any blocks force pushes, force pushes are blocked. Nothing can *un-require* something another source requires. ## Enforcement status filters, it does not weaken A ruleset set to `disabled` is simply not in the collection. A ruleset in `evaluate` mode (available on plans that offer it) is evaluated and its would-be violations are recorded in rule insights, but it does not block the operation. This is the mechanism for staging a stricter baseline: publish it in evaluate, watch which repositories and which people trip it, fix them, then flip to active. ## Bypass is per-ruleset, not global Each ruleset carries its own `bypass_actors`. If you are in the bypass list of the organization baseline ruleset, you are exempt from **that ruleset's** rules; a team ruleset that also targets `main` still applies to you in full, and so does classic branch protection, whose exemption is governed by its own "Do not allow bypassing the above settings" toggle. So the real question in an incident is not "am I an admin" but "which of the applicable sources exempts me, and is it the one carrying the rule that is blocking me". Bypasses that do fire are recorded, which is what makes a break-glass path acceptable at all. ## Targeting subtleties that bite - Ref conditions use name patterns plus special targets such as the default branch and all branches, and support both include and exclude lists. An exclude in one ruleset removes only that ruleset from the collection — it does not exclude the branch from anybody else's rules. - Organization rulesets can target repositories by **repository property**, so changing a property value silently changes which policies apply to a repository. Treat property changes as policy changes. - Tag rulesets and push rulesets are separate targets; a branch ruleset never governs tag pushes, so "main is protected" says nothing about whether release tags can be moved. ## How to actually find out Do not reason from screens. Ask GitHub for the effective rules on the branch. The response lists each rule that currently applies with the source it came from — repository or organization, and the identifier of the ruleset — which turns "why can't I merge" into a one-request answer. For classic protection, the branch protection endpoint returns the rule as its own object. Rule insights on the organization or repository shows the history: which rules were evaluated for a given push or merge, what passed, and who bypassed. ## Migration hygiene Running both models permanently is legal and occasionally deliberate, but usually it is an accident of a half-finished migration, and it costs you comprehensibility: two places to look, two mental models, and a stricter-wins interaction nobody remembers. A clean migration is: capture the effective rules, express them as one ruleset, publish it in evaluate mode alongside the classic rule, confirm rule insights shows it would block exactly the same things and nothing more, switch it to active, then delete the classic rule. Deleting the classic rule first is the version of this that produces an unprotected window. ## Interview framing Lead with "all of them apply, strictest wins, nothing relaxes anything". Then add the two details that show real operational exposure: bypass is scoped to the ruleset that grants it, and the way to answer the question in practice is the branch rules endpoint rather than clicking through settings. Mentioning evaluate mode as the safe way to add a source to the stack rounds it out.