Protected Branches

The Hook (The "Byte-Sized" Intro)

Without protection, anyone can git push --force to main — deleting history, bypassing reviews, and deploying untested code. Protected branches make this impossible. No direct pushes. No merges without reviews. No deploys without passing tests. They're the last line of defense between your codebase and chaos.

📖 What are Protected Branches?

Rules configured on a repository that restrict what actions can be performed on specific branches, enforcing quality gates before code reaches production.

Conceptual Clarity

Key protection rules:

Rule	What It Prevents
Require PR reviews	Direct pushes to branch
Require status checks	Merging without passing CI
Require up-to-date branch	Merging stale branches
Block force pushes	Rewriting history on protected branch
Block deletions	Deleting the branch
Require code owner review	Merging without owner approval
Require signed commits	Unsigned commits
Restrict who can push	Limit push access to admins

Typical setup for main:

Setting	Value
Require PR	✅ Yes
Min reviewers	1-2
Dismiss stale reviews	✅ Yes
Require CI pass	✅ Yes
Require branch up-to-date	✅ Yes
Block force push	✅ Yes
Block deletion	✅ Yes
Include admins	✅ Yes

Real-Life Analogy

Protected branches are like bank vault procedures. No single person can open the vault alone — you need multiple keys (reviewers), a security check (CI), and authorization (code owner approval).

Visual Architecture

flowchart LR PR["📋 Pull Request"] --> REVIEW["👀 1-2 Reviews"] REVIEW --> CI["✅ CI Passes"] CI --> UPTODATE["🔄 Branch Up-to-Date"] UPTODATE --> MERGE["🔀 Merge to Main"] style PR fill:#1a1a2e,stroke:#ffd700,color:#ffd700 style MERGE fill:#1b2d1b,stroke:#53d8fb,color:#53d8fb

Why It Matters

Safety: Prevents accidental or malicious direct pushes to main.
Quality: Every change is reviewed and tested before merging.
Compliance: Required for SOC2, HIPAA, and other audit frameworks.
Trust: Everyone trusts that main is always deployable.

Code

bash

# ─── GitHub CLI: set branch protection ───
gh api repos/{owner}/{repo}/branches/main/protection \
  --method PUT \
  --input - << 'EOF'
{
  "required_pull_request_reviews": {
    "required_approving_review_count": 1,
    "dismiss_stale_reviews": true
  },
  "required_status_checks": {
    "strict": true,
    "contexts": ["ci/tests", "ci/lint"]
  },
  "enforce_admins": true,
  "restrictions": null
}
EOF

# ─── What happens without protection ───
git push --force origin main     # ← Rewrites shared history!
git push origin main             # ← Bypasses code review!

# ─── What happens WITH protection ───
git push origin main
# ❌ remote: error: GH006: Protected branch update failed
# ❌ Changes must be made through a pull request

Key Takeaways

Protect main (and release/*) with PR requirements and CI checks.
Block force pushes and deletions on protected branches.
Include admins — nobody should bypass the rules.
Protected branches are required for compliance (SOC2, HIPAA).

Interview Prep

Q: What are branch protection rules? A: Rules configured on a repository that prevent direct pushes, require PR reviews, enforce CI checks, and block force pushes on critical branches like main.
Q: Why should admins also be subject to branch protection? A: To prevent shortcuts and maintain trust. If admins can bypass rules, security and quality guarantees are weakened. Emergencies should use established hotfix workflows, not rule bypasses.
Q: How do protected branches support compliance? A: Frameworks like SOC2 and HIPAA require evidence that code changes are reviewed and tested. Branch protection provides an automated audit trail of reviews, CI results, and approvals.