Branch protection

What it is

Branch protection is a set of repository controls for an important branch such as main or a release branch. Azure Repos calls the review conditions branch policies. The controls can require a pull request, review, successful checks, and particular merge behavior before the protected branch changes.

Why it exists

The main or release branch is usually the shared version from which teams build or deploy. Protecting it turns “please get a review” from a memory-based convention into an enforceable rule.

Key ideas

• Policies define completion requirements. Examples include a minimum number of reviewers, linked work items, resolved comments, build validation, status checks, automatically included reviewers, and allowed merge types.
• Permissions decide who can bypass. In Azure Repos, permissions can allow bypass when completing a PR or bypass when pushing. Give those permissions sparingly and audit their use; a policy cannot protect a branch when broad bypass access is available.
• Policies are target-branch specific. A PR into main is evaluated by main’s policy, so do not assume a temporary feature branch needs the same long-lived controls.
• Keep rules useful. Required checks should be fast, reliable, and relevant to the risk. A flaky gate trains people to seek bypass rather than improve quality.
• This is source-control governance. It does not replace cloud RBAC, a production deployment approval, or testing a completed deployment.

Northwind example

Northwind protects main with a PR requirement, two approvals for production-impacting changes, a passing build, and resolved comments. It automatically adds the payment-team reviewer when files under payments/ change. Only a small emergency group can bypass policy, and it must document the reason. The policy prevents an unreviewed commit entering main; it does not by itself authorize a person to deploy to production.

Related

pull-request · branching-strategy · pipeline-security · deployment-environment