The Green Checkmark Is Not Branch Protection
Why a passing CI check still lets a PR merge without branch protection turned on, the two settings that actually stop it, and the honest pros and cons of a stable-stage pipeline.
ci.yaml runs on every pull request now, and it shows a green checkmark when it passes. That checkmark looks like a gate. It is not one, on its own.
A failed check still lets you merge
Turn ci.yaml's check red on purpose, on a PR, with no branch protection configured. The merge button is still there, still clickable, still works.
A required check only blocks a merge if a branch protection rule says so. Without that rule, the status check is informational. It tells you something, it doesn't stop anything.
This is genuinely easy to miss, because the UI doesn't warn you. A green check looks identical whether it's enforced or purely cosmetic, and plenty of real projects ship for months with checks nobody can actually fail to merge past.
The two settings that make it real
Branch protection lives under repo Settings → Branches. Adding a rule for main asks for two separate things, and both matter:
Blocks direct pushes to main. A PR with a failing check can still be merged, nothing checks the result.
Name the exact job (GitHub autocompletes it from prior runs). Now the merge button stays disabled until that job is green.
Adding required approvals on top means at least one other person, not you, has to approve before merge. Enabling that is a real decision: it means the project owner is no longer exempt from the same review everyone else goes through. That's the whole point of it, but it's worth choosing on purpose, not by default.
What stage two actually bought
Three files changed, one setting flipped, and the pipeline crossed a real line.
Bad code can't reach main without review. Builds are cached and fast. One build definition, shared by CI and CD, not two copies drifting apart.
Long-lived AWS keys are still sitting in repo secrets. Deploy still ships automatically on every merge, no human gate. Actions are pinned to mutable version tags, not commit hashes. The S3 bucket is still a public bucket with no CDN in front of it.
None of those cons are accidents. Naming them is what makes stage three worth doing. A pipeline that's fast, reviewed, and built from one shared definition is a real, honest improvement over a proof-of-concept, even while a handful of specific, known risks are still sitting there, waiting for the stage that's actually built to close them.
The Essentials
- A required check only blocks a merge if branch protection says so. A green checkmark by itself is informational, not a gate.
- Branch protection needs two things: require a pull request, and require the specific status check by name. Either one alone leaves a gap.
- Required approvals mean the owner reviews like everyone else. That's the actual tradeoff, not a formality.
- Naming a pipeline's known gaps is progress, not failure. Stage two's cons are exactly the list stage three exists to work through.
Further Reading and Watching
Keep reading