What is a Risky Merge?
A Risky Merge means a change is merged into a branch (often main or production) even though it could introduce problems.
Typical cases of risky merges include:
- Checks not passed → CI/CD tests, linting, or security scans failed.
- Missing approvals → Required reviewers (e.g., Sr. Dev, QA, or Security) didn’t sign off.
- Too few reviewers → The team policy says 2+ approvals, but only 1 was given.
- Merging late/odd hours → e.g., after 5 pm Friday, when no one is around to fix issues.
- Unverified hot-fixes → Skipping tests to push emergency fixes without validation.
- Conflicting or outdated branches → Code merged without resolving conflicts or rebasing.
Warestack protection
Warestack protects your branches by preventing risky or unauthorized pull request merges.
This includes PRs with missing reviewers, skipped checks, missing descriptions, or changes to critical paths.
Problem: Standard tools are not enough
GitHub’s default protection rules aren’t enough. Without context-aware enforcement, risky changes often get merged unnoticed — breaking builds, introducing regressions, or creating audit gaps.
Risky merges are one of the top causes of production issues.
Warestack continuously monitors every PR, enforces your team’s merge rules, and blocks anything that looks unsafe — automatically.
It’s like having a policy reviewer on every branch.
Risky Merge Rules
- Missing Reviews → Block pull requests that have fewer than 2 reviewers or were approved by the author themselves.
- Skipped Checks → Detect and block PRs where GitHub Actions were skipped or failed before merging.
- Sensitive Code Paths → Flag PRs that touch protected paths like
/infrastructure,/auth, or.github/workflows/. - Label-Based Blocking → Block PRs with
hotfix,security, orbypass-reviewlabels unless approved by a lead or a security role. - Enforcement Logs → Warestack keeps a full log of violations, decisions, and remediation steps — useful for audits and reviews.