Branch Policies in Azure DevOps are branch-level rules that define the conditions under which a pull request may be completed. In Azure Repos, they govern review requirements, technical checks and traceability before a merge.
In operational terms, this means they do not simply protect “the branch”; they define a mandatory review path for changes to important target branches. A pull request is the proposed set of changes that is reviewed and approved before it is taken over.
According to Microsoft Learn, “Branch policies and settings” and “About branches and branch policies” (accessed on 01/11/2026), the key policies in Azure Repos are disabled by default. You configure them deliberately for each branch, for example for:
- minimum number of reviewers
- linked work items
- resolved comments
- build validation
- status checks
- automatically included reviewers
- permitted merge types
This article is aimed at platform and DevOps owners who run and secure Azure DevOps Services or Azure DevOps Server in their organisation. Differences between Services and Server are mentioned only where they matter in practice.
Why you should protect branches
Unprotected target branches quickly turn review rules into informal custom: one repository is reviewed rigorously, the next gets only a quick glance, and in a third people push directly if in doubt. Operationally, that is risky, because approval, traceability and technical checks then vary from team to team.
Branch Policies draw a clear line here. They define which conditions must be met before a pull request can be completed. A pull request is the proposed change that is reviewed before it is taken into the target branch.
In practice, the main benefits are threefold:
- Reviews are not just expected; they are enforced.
- Open discussions remain visible until they are resolved.
- Changes can be cleanly assigned to a work context and a review step.
What matters here is the distinction between rule and right. A policy defines the review path in the pull request. Whether someone may still push directly, bypass policies or complete a merge is governed by permissions. For that side of protection, the classification in Rights around push, merge and bypass is relevant.
Protecting branches therefore does not mean making Git restrictive. It means defining a reliable standard for sensitive target branches.
The most important Branch Policies at a glance
According to Microsoft Learn, “About branches and branch policies” and “Branch policies and settings” (accessed on 01/11/2026), Azure Repos includes these core policies: minimum number of reviewers, linked work items, resolved comments, restricted merge types, build validation, status checks and automatically included reviewers. All of them are switched off by default, so they only take effect once you deliberately configure them per branch.
The Minimum number of reviewers policy defines how many approving votes a pull request must have before it can be completed. In practice, this is often the core of your review requirement, because it determines whether changes have merely been read or have actually been formally approved.
This reviewer policy includes several options that can significantly change the process:
- Whether requesters may approve their own changes.
- Whether the person who made the last push is excluded from approving.
- Whether completion despite votes such as “wait” or “reject” is allowed or prevented.
- Whether at least one approval on the latest iteration is required after new pushes.
An iteration is each new state of a pull request after additional commits or updates.
According to Microsoft Learn, “Branch policies and settings” (accessed on 01/11/2026), you can also have votes reset after new pushes. This allows you to reset either all approvals or reviewer votes more generally. In Azure DevOps Server 2022.1 and later, there is also the option to require approval on every iteration. Especially for pull requests that are frequently revised, this is not a minor detail but a deliberate decision about how far new changes should invalidate earlier approvals.
The Check for linked work items policy requires a pull request to be linked to a work item. That keeps a change tied to a business or technical task. This is often useful when you expect traceability not only in the commit history but also between board and repository.
With Check for comment resolution, you ensure that open review discussions are cleared before completion. This keeps review feedback visible in the process instead of letting it be silently bypassed by a merge at the end.
Limit merge types controls which merge strategies are permitted on a branch. If you would like to explore the differences in pull request workflows in more depth, you will find a suitable classification in Draft and completion paths for pull requests.
The important point about this policy is how to classify it: according to Microsoft Learn, “Secure your Git repo” (accessed on 01/11/2026), it is not a direct security control but more a matter of history governance. Squash creates a more compact target history, but combines the commits of the source branch into a single commit. If your audit model depends on the precise sequence of commits, merge-commit strategies may be a better fit.
Build Validation, Status Checks and automatically included reviewers complement this basic framework. Status Checks in particular are often the point at which a simple review rule becomes a mandatory review path. You can read how to use such signals specifically as a required check in the article on Using status messages as a policy.
How to set up a sensible baseline for main
Treat main as a particularly protected target branch. As a starting point, it is usually more sensible to combine a small number of rules clearly and consistently than to build in many special cases and exceptions too early.
Based on Microsoft’s recommendations, this combination is a practical baseline for main:
- at least two reviewers
- linked work items
- resolved comments
- build validation
- automatically included reviewers for sensitive paths
- tightly restricted bypass rights
According to Microsoft Learn, “Secure your Git repo” (accessed on 01/11/2026), this exact set is part of the recommended protection for main. The benefit comes from the interplay: reviewers cover business and technical questions, work items provide traceability, comments prevent unresolved review leftovers, builds ensure a minimum technical standard, and automatically included reviewers bring the necessary domain knowledge to the right places.
Sensitive paths are not limited to application code. They often also include infrastructure definitions, pipeline files or permission-related configurations.
Status Checks are especially useful when you want to attach additional review paths to the pull request beyond the build pipeline. The more detailed article on status messages as required checks shows how to integrate this as a mandatory check.
You should choose merge types deliberately according to your revision and audit model, not as a blanket security feature. Review this baseline regularly, for example after changes to pipelines, team structure or repository layout.
What to watch for with Services, Server and AI-assisted reviews
Branch Policies themselves are not the area where Services and Server differ greatly. The differences become relevant in adjacent AI features and in the operating model around them.
For Azure DevOps Server, the point is this: newer AI-assisted review features are not automatically available there. According to Microsoft documentation, Copilot Code Review was not available for Azure DevOps Server on 24/10/2026; Microsoft describes its AI route in this area via Azure DevOps Services. In addition, you should also check the product lifecycle of your Server version: according to Microsoft Lifecycle documentation, checked on 24/10/2026, Azure DevOps Server 2022 has mainstream support until 11/01/2028 and extended support until 11/01/2033.
In Azure DevOps Services, according to Microsoft Learn, “Copilot code reviews” and “Review pull requests” (accessed on 01/11/2026), Copilot Code Review is available as a Public Preview. Operationally, three limitations matter most:
- It reviews only active pull requests without merge conflicts.
- It works only in repositories up to 10 GB.
- It processes at most 100 changed files and 100 changes.
What matters for your policy design is this: these reviews appear as Comment Review. That means they do not fulfil any Required Reviewer policy and do not enforce a merge stop.
A second point is the data path. According to the Microsoft Learn FAQ, “Copilot code reviews FAQ” (accessed on 01/11/2026), processing does not follow the data residency boundaries of your Azure DevOps organisation; for EU-hosted organisations, processing may also take place in other geographies. Whether that fits your requirements for data protection, DORA, NIS2 or co-determination should be checked with your legal department, solicitor or data protection officer.
Frequently asked questions about Branch Policies in Azure DevOps
When are Status Checks more useful than Build Validation alone?
As soon as signals beyond the pipeline also need to become mandatory. Build Validation covers the build path. Status Checks are more open-ended and are suitable for additional approvals or technical feedback from connected systems.
For implementation, Service Hooks for pull requests or Pull requests via the REST API are often the practical starting point.
What happens to reviewer votes after new commits in the pull request?
That depends on the reviewer policy you have chosen. In Azure Repos, you can define whether at least one approval on the latest iteration is required after new pushes or whether votes are reset. An iteration is a new state of the pull request after additional commits.
Especially in longer reviews, this setting determines whether earlier approvals remain valid or whether changes must be reviewed again.
Do Branch Policies also help with automatically created pull requests?
Yes, provided the pull request targets a protected branch. The policy applies at the target branch, not based on whether a person or a process created the pull request. For the team workflow, what matters more is how a pull request is created and which checks are then mandatory.
What is the most common misconception in day-to-day work about “Limit merge types”?
It is often treated as a security measure. In reality, it primarily controls the shape of the target history. That matters for audit and traceability, but it is not the same as review, comment or build requirements.
In practice, this often only becomes visible when teams more frequently have to resolve merge conflicts and the chosen strategy affects the pull request workflow.
When should I fundamentally review my policy strategy?
Not only after an incident. Typical triggers are:
- new repository structures
- changed responsibilities
- new review automation
- a planned platform change
Especially for the last point, a classification in Azure Repos or GitHub helps, because Branch Policies are only one part of the target architecture.
Next step
Your next step should be to define a fixed operational standard for protected target branches: responsibilities, exceptions, review paths and how often the settings are reviewed. That is how individual policies become a model that remains operable in the long term.
Especially for automated review or change steps, you should also keep three questions clearly separate:
- What is technically enforced?
- What is only expected organisationally?
- Which points should you review with your legal department, solicitor or data protection officer in relation to data protection, DORA, NIS2 or co-determination?
If you would like to follow the progress of Polier: as of 01/11/2026, the service is in development and not available. You can find the currently described status on the Security and data page, changes in the public changelog, the planned route to sign-up on the Pricing page, and future metrics on the Results page.