How do you rebuild branch protection for a new monorepo?

A new monorepo does not inherit branch protection from the repositories you merged. Set it before the first team pushes: require pull requests, required reviews with code owner approval, status checks with unique job names, and an owner for the CODEOWNERS file itself. Then test that the rules block what you expect.

Why the gap appears

Branch protection is a repository setting. GitHub's documentation describes rules that define whether collaborators can delete or force push to a branch and that set requirements for pushes, such as passing status checks or a linear commit history. Importing history copies commits, not settings. For a few days the main branch of a freshly created repo may accept direct pushes.

The checklist

1. Create the rule or ruleset on the default branch before you import or open it to teams.
2. Require a pull request before merging, with at least one approving review. The documentation says that with required reviews, changes reach a protected branch only through an approved pull request.
3. Require review from code owners, so a change to owned paths needs the owner's approval. When code owner review is required, an approval from any listed owner on the line satisfies it.
4. Require that the most recent reviewable push is approved by someone other than the person who pushed it.
5. Require status checks. Pick the checks that matter: build, tests, dependency scan, static analysis.
6. Make job names unique. The docs warn that the same job name in multiple workflows can cause ambiguous status check results and block merges.
7. Block force pushes and deletion of the branch.
8. Include administrators, or document exactly who may bypass and why. Our note on branch protection and admin bypass explains the default.
9. Put an owner on the CODEOWNERS file. The docs say the most secure method is a file in .github/ with the repository owner owning that file or directory.
10. Protect tags and release branches too. A ruleset can do that, see protect release tags with a ruleset.

Naming checks in a monorepo

In separate repos, each had a single check called test. In one repo, ten workflows may each define a test job. Prefix names with the service, such as payments / test. Then check the path filter problem: a required check that never runs because of a path filter can sit pending, covered in required status check stuck pending.

Branch rules or rulesets

The CODEOWNERS documentation notes that rulesets have advantages over branch protection rules, such as statuses and discoverability without admin access, and that several can apply at once. For an organization with many repos, see GitHub rulesets to enforce security checks on every repo.

Test the rules

Open a pull request with a failing check and confirm it cannot merge. Try to push directly from an account without bypass. Capture a screenshot or export of the settings as evidence.

Try it yourself

Click through it at your own pace, or open it full screen.

Click through the pull request gate and watch what happens when a check fails.

Safeguard's policies, gates and guardrails can add a dependency and vulnerability gate to the required checks.

Quick check

Sources

• GitHub Docs: About protected branches
• GitHub Docs: About code owners

Last reviewed: 19 October 2026.