Branch Protection Rules: The First Line of Engineering Governance

What Branch Protection Actually Is

Branch protection rules are the guardrails of your repository. They prevent direct commits to critical branches, enforce code review before merging, require status checks to pass, and block force pushes that rewrite history. In a platform like GitHub or GitLab, they're a small configuration that amounts to a massive governance statement: "We do not ship untested, unreviewd code to production."

Without branch protection, your main branch is open to chaos. Commits push directly without review. One developer can overwrite another's work. Tests can fail silently and code still merges. Compliance auditors see this and mark you as "ad-hoc" or "immature." Security assessors flag it as a risk. The CRA sees it as evidence that secure-by-design principles aren't enforced in your development workflow.

Why It Matters

Branch protection enforces quality at the point of merge. It's a structural control, not a cultural one. You can't accidentally (or deliberately) bypass it. Every change to your main branch is traced, reviewd, and gated. This creates a verifiable record for compliance.

It also prevents the silent breakdown that kills teams. When branch protection is loose, one person starts committing directly "just this once." Then another follows. Then the team norm shifts from "code review is required" to "code review is optional." Six months later, you have no reviews at all.

Tight branch protection prevents this drift. It forces intent. Everyone knows the rules, and the rules are enforced by the system, not by hope.

Common Configurations

Mature branch protection includes:

• Required reviewers: Typically 1–2 approvals before merge. Some teams require different reviewers from the change author.
• Status checks: Tests, linting, security scans, and build steps must pass before merge is allowed.
• Dismiss stale reviews: If code changes after approval, reviews are invalidated and new approval is required.
• Block direct pushes: No direct commits to main; all changes must come through pull requests.
• Restrict force pushes: Prevent history rewriting, which obscures changes and breaks traceability.
• Require branches to be up to date: Force rebase or merge to main before allowing merge, catching integration issues early.

How to Implement

In GitHub, navigate to your repository's Settings → Branches. Create a branch protection rule for your main branch (or master, or however you name it). Enable the configurations above. Test it: try to commit directly to main — the system should reject you.

In GitLab, the pattern is similar: Settings → Repository → Protected Branches. Configure required approvals, status checks, and push permissions.

The key is that this is not a "one and done" configuration. Audit it quarterly. As your team grows, your rules may need to evolve. But the baseline — no unreviewed code merges to main — should remain inviolate.

How Concordance Scores It

Concordance connects to your GitHub or GitLab instance and reads your actual branch protection configuration. It checks:

• Is branch protection enabled on main?
• Are required reviews enforced? (And by how many reviewers?)
• Are status checks required to pass?
• Are force pushes blocked?
• Is dismissing stale reviews configured?

A repository with full protection (all checks enabled) scores highest. One with no protection scores at the baseline. This isn't a guess—it's reading your actual policy.

CRA Relevance: Secure-by-Design Evidence

The Cyber Resilience Act (CRA) requires "secure-by-design" development. One of the clearest pieces of evidence that you design security in—rather than bolting it on—is enforced code review and branch protection. It shows that every line of code shipping to production has been reviewed by a human. It shows that your tests must pass before merging. It shows that history isn't rewritten to hide changes.

CRA reporting (first due September 11, 2026) asks: "What controls do you have over code changes?" Branch protection is the answer. Without it, you're telling an auditor that anyone can push code to production without review.