A new repository is the cheapest time to set rules, because nobody is relying on the old way. This checklist covers ten settings: protected default branch, required reviews, code owners, required checks, stale approval handling, force push, signing, secret protection, a template and a hooks config.
1. Protect the default branch
Use a branch protection rule or a ruleset. GitHub's documentation says both can enforce reviews and checks. Rulesets have the advantage that read access lets anyone view active ones, so auditors and developers can see what applies.
2. Require pull request reviews
Set a number of approving reviews. Even one is a real control for a small team. A review requesting changes blocks the merge until resolved.
3. Add CODEOWNERS
Start with auth, workflows and infrastructure. See requiring code owner review.
4. Require status checks
Decide which checks are required, and check that none can be skipped by path filters. See required checks and skipped results.
5. Dismiss stale approvals
So an approval applies to the code that was reviewed. See what the setting protects.
6. Block force pushes
The protected branches documentation says force pushes are blocked by default and can be allowed for specific people. Leave it off on the main branch, since rewriting shared history erases evidence.
7. Consider signed commits
Only signed and verified commits can be pushed to the branch. Make sure everyone has a key first. See what the Verified badge means.
8. Turn on secret protection
Push protection blocks hardcoded credentials before they reach the repository. Repository level protection needs GitHub Secret Protection and is off by default, according to the documentation, so it is a setting you must enable.
9. Add a pull request template
A short risk section. See the template guide.
10. Commit a hooks config
A short .pre-commit-config.yaml with pinned revs and a setup script, backed by the same checks in CI.
Decide on admin bypass
By default admins are exempt from branch protection. The documentation describes a setting that applies the rules to admins as well. Choose, and write down why.
Revisit it
Put a calendar reminder to review the settings every six months, or when team size changes.
A free scan of your dependencies is available at gold.safeguard.sh/scan.
Making it repeatable
Do not click through ten settings by hand for every repository. Write the checklist into your onboarding doc, or manage settings through your platform's rule features across a whole organization when available. Rulesets can apply to many repositories, though the documentation notes organization level rulesets are for Enterprise plans.
After creation, open the repository settings once and compare them with the list. Fixing a gap in week one is much easier than after the first release.
Quick check
Branch protection or rulesets?
Either can do the job. GitHub says multiple rulesets can apply at once and the most restrictive rule wins, and that rulesets are visible to anyone with read access.
Sources
- GitHub Docs: about protected branches
- GitHub Docs: about rulesets
- GitHub Docs: about push protection
Last reviewed: 19 October 2026.
