Challenge 2: Restrict Production Deploys to main — Possible Solution ==================================================================== THE CONCRETE SCENARIO THIS PREVENTS ---------------------------------------- Imagine a developer is working on a feature branch called experimental-checkout-redesign — code that's incomplete, untested against real integrations, and never intended to reach real users yet. Without deployment branch restrictions configured on the production environment, if that developer's workflow (perhaps through a misconfigured trigger, a manual workflow_dispatch run pointed at the wrong branch, or simply a copy-pasted workflow file with the wrong branch assumption) ends up targeting the production environment, there would be NOTHING stopping a job running against experimental-checkout-redesign from deploying that unfinished, untested code directly to real production infrastructure. WHAT THE RESTRICTION ACTUALLY DOES --------------------------------------- With deployment branch restrictions configured on the production environment to allow ONLY main, GitHub Actions checks — as part of the environment's protection rules, in addition to any required reviewers — whether the branch a job is currently running from is on the allowed list. If a job attempts to deploy to the production environment from experimental-checkout-redesign (or any branch other than main), GitHub blocks it from proceeding at all, regardless of whether required reviewers might have otherwise approved it — the branch itself simply isn't eligible to trigger a production deployment. WHY THIS MATTERS AS A DISTINCT PROTECTION FROM REQUIRED REVIEWERS ------------------------------------------------------------------------ Required reviewers protect against "someone approves a genuinely bad deploy" — a human judgment failure. Branch restrictions protect against a DIFFERENT category of mistake entirely: a deployment being triggered from the WRONG SOURCE altogether, regardless of whether anyone ever reviews it. A reviewer approving a production deploy assumes they're reviewing a deploy of the intended, merged, tested code on main — if the underlying branch were actually some unrelated feature branch, even a careful reviewer might not immediately realize that's the case unless the workflow interface makes it obvious. WHY THIS WORKS AS AN ANSWER ------------------------------ This directly matches this chapter's own description: deployment branch restrictions exist specifically for "preventing an accidental deploy from a feature branch" — the feature-branch scenario given here is precisely the kind of concrete mistake this protection rule is designed to structurally rule out, rather than relying on human vigilance (via reviewers) to catch it after the fact.