Protect important branches with permissions and rules

A team should not rely only on everyone remembering the process. GitHub can enforce important merge requirements at repository level.

Repository access determines who can read, triage, write, maintain or administer depending on account type and plan. Branch protection and rulesets can require pull requests, approvals, status checks, linear history, signed commits or other conditions.

For high-traffic branches, a merge queue can retest changes against the latest integration state before merging. Availability and exact settings depend on repository ownership and plan.

Run this in a disposable practice repository unless the lesson explicitly says otherwise.

# Most rules are configured in GitHub repository settings.
# Verify local branch before pushing:
git status
git log --oneline --decorate -5

For a small team, a practical starting policy might require a pull request, at least one approval, passing CI and no unresolved conversations before main can change.

Your task: Design rules for a 4-person team: who can push to main, how many approvals are needed, which CI job is required, and who may bypass the rule in an emergency.

Too many rules can create unnecessary friction; too few can make the default branch fragile. Start from actual risks and team size, then adjust using evidence from incidents and workflow delays.

Protect important branches with permissions and rules is complete when you can explain the state being changed before you run the command, not merely repeat the syntax.

Read further: official supporting documentation.