Branch Protection Rules - Secure Your Git Branches

Picture this scenario: it is 11 PM on a Friday, a developer pushes a "quick fix" directly to the main branch, skipping code review and tests. The change breaks the production deployment pipeline, and the entire team spends their weekend debugging. Branch protection rules exist to prevent exactly this kind of disaster.

Branch protection is a set of policies you configure on GitHub that restrict what can happen to specific branches. They enforce code review, require tests to pass, prevent force pushes, and ensure that no single person — not even administrators — can bypass your team's quality gates.

Why Branch Protection Matters

Without protection, any developer with write access can:

• Push directly to main, bypassing code review
• Force push and rewrite history others depend on
• Delete critical branches
• Push broken code that fails tests
• Merge without any approval

With protection enabled, every change must go through your defined process — no exceptions.

Setting Up Branch Protection

Navigate to: Repository → Settings → Branches → Add branch protection rule

Essential Protection Rules Explained

Require Pull Request Reviews

This is the most important rule. It prevents any code from reaching the protected branch without human review:

Why 2 approvals? The "four-eyes principle" ensures at least two people have seen every change. It catches bugs, improves knowledge sharing, and provides accountability.

Why dismiss stale approvals? If a PR was approved but then new commits are pushed, the previous approval may no longer be valid. Dismissing forces re-review.

Require Status Checks

Status checks are automated verifications (CI/CD) that must pass before merging:

"Require branches to be up to date" means the PR branch must include the latest commits from the base branch. This prevents a scenario where two PRs pass tests individually but conflict when merged together.

Prevent Force Pushes and Deletions

Force pushing to a protected branch rewrites history that your entire team depends on. Deletion of main or release branches would be catastrophic. These should always be disabled.

Additional Security Rules

Include administrators is often overlooked but essential. Without it, admins can bypass all rules, defeating the purpose of protection.

Rulesets: The Modern Evolution

GitHub Rulesets (newer feature) provide more flexibility than traditional branch protection:

Rulesets advantages over traditional branch protection:

• Apply to multiple branches at once
• Support bypass lists for automation
• Can be stacked (multiple rulesets on same branch)
• Organization-wide rulesets

CODEOWNERS Integration

CODEOWNERS works with branch protection to require review from domain experts:

When "Require review from Code Owners" is enabled in branch protection, PRs that touch these paths automatically require approval from the designated team.

What Happens When Rules Are Violated

remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Required status check "ci/test" is expected.
remote: error: At least 2 approving reviews are required by reviewers with write access.
To github.com:org/project.git
 ! [remote rejected] main -> main (protected branch hook declined)

The push is cleanly rejected with a clear explanation of which rules were violated.

Common Mistakes

Mistake 1: Not enabling "Include administrators." This creates a false sense of security where admins can bypass all rules, and accidental direct pushes from admin accounts go undetected.

Mistake 2: Requiring too many status checks without ensuring they are fast. If CI takes 45 minutes and every push needs re-checking, developer productivity tanks. Keep required checks fast.

Mistake 3: Not using "Dismiss stale approvals." Without this, a developer can get approval on a 5-line change, then push 500 additional lines before merging without re-review.

Mistake 4: Protecting only main but not release branches. If your release branches are unprotected, emergency hotfixes can bypass all quality controls.

Interview Questions

Q1: What are branch protection rules and why are they important?

Branch protection rules are GitHub policies that enforce processes on specific branches. They require pull request reviews, passing CI checks, signed commits, and prevent force pushes. They ensure code quality, prevent accidental damage, and enforce team workflows regardless of individual developer actions.

Q2: Should administrators be subject to branch protection rules?

Absolutely. Enable "Include administrators" for genuine security. If admins can bypass rules, the protection is merely advisory. Every person should go through the same process, with bypass only available through emergency break-glass procedures with full audit logging.

Q3: What status checks should be required before merging?

At minimum: unit tests, linting, and build verification. Additionally consider: security scanning (CodeQL, Snyk), type checking, integration tests, and coverage thresholds. The checks should be fast (under 10 minutes) to avoid blocking developer workflow.

Q4: What happens when someone tries to push directly to a protected branch?

The push is rejected with an error message listing which protection rules were violated. The developer must instead create a branch, open a pull request, get the required approvals, pass status checks, and merge through the PR interface.

Q5: How do CODEOWNERS work with branch protection?

When "Require review from Code Owners" is enabled, any PR that modifies files matching CODEOWNERS patterns automatically requests and requires approval from the designated owners. This ensures domain experts always review changes to code they are responsible for.