Branch Protection and Rulesets

## Where the rule actually lives A protected branch is a **server-side** policy on GitHub, not a setting in your working copy. Your local Git happily creates commits on `main`, because your clone has no idea any policy exists. The check happens when `git push` sends the ref update to GitHub: the receiving side looks at every rule targeting `refs/heads/main` — a classic branch protection rule, one or more rulesets, or both — and either accepts or refuses the update. This is why a colleague can commit to `main` locally all day and only discover the policy at push time. ## What the rejection looks like The transport reports a per-ref failure, so the push fails atomically for that ref. The `remote:` lines are GitHub speaking. `GH006: Protected branch update failed for refs/heads/main` is the classic branch-protection code, followed by a human-readable reason such as `Changes must be made through a pull request` or `At least 1 approving review is required by reviewers with write access`. When the rule comes from a ruleset instead, the message names the ruleset and the specific rule that was violated. Either way, the exit status is non-zero, and Git's summary line is `error: failed to push some refs to ...`. ## Nothing is lost A rejected push changes nothing anywhere. The commits still exist in your local repository, reachable from your local `main`; the remote's `main` is byte-for-byte what it was. This matters because the panic reaction — `git push --force`, or `git reset --hard` to "clean up" — is exactly what destroys work. Force is useless here anyway: the rule rejects the update regardless of how it is expressed, and a separate rule normally blocks non-fast-forward pushes outright. ## The intended path Move the work onto a branch and open a pull request: 1. `git switch -c feature/rate-limit` — the branch now points at your commits. 2. `git switch main && git reset --hard origin/main` — put local `main` back in sync with the remote. 3. `git push -u origin feature/rate-limit`, then open the PR. The PR is where the rest of the policy gets applied: required approvals, required status checks, conversation resolution, and whatever else the branch's rules demand. Merging through the PR is a merge performed **by GitHub on the server**, which the rules explicitly permit; a direct push is what they forbid. ## Related rules you may hit instead "Require a pull request before merging" is only one of several rules that reject a push: - **Restrict who can push** (classic) / **restrict updates** (rulesets) — pushes are allowed, but only from listed people, teams or apps. - **Block force pushes** (`non_fast_forward` in rulesets) — normal pushes are fine, history rewrites are not. - **Restrict deletions** — `git push origin :main` is refused. - **Require signed commits** (`required_signatures`) — an unsigned commit in the pushed set is rejected. - **Lock branch** — the branch is read-only entirely, including for merges. Each produces its own reason line, so read the `remote: error:` text rather than guessing. ## Can an admin get through? Only if configured. Classic branch protection has a **"Do not allow bypassing the above settings"** checkbox; leave it on and admins are held to the same rules. Rulesets express the same idea as an explicit **bypass list** of roles, teams and GitHub Apps, optionally scoped to "for pull requests only" (they may open and merge PRs that skip a rule, but still cannot push directly). A repository where everyone believes "admins can always push" almost always has a bypass entry someone forgot about, and the bypass is recorded — rulesets surface it in rule insights and the organization audit log. ## Interview framing The point of the question is whether you understand that policy is enforced by the hosting platform at receive time, not by your Git client, and that a rejected push is a safe, reversible state. Say that, name the error you would read, and describe the branch-plus-PR recovery, and you have answered it fully.