To create a pull request in Azure DevOps, push a branch containing your changes to Azure Repos and open a pull request from it against the target branch. Then add the review details and complete the pull request only once the target branch requirements have been met.
A pull request is the formal proposal to bring changes from a source branch into a target branch. It brings together the diff, review, comments and checks in one place.
In practical terms, creating one comes down to:
- choosing the right source and target branch
- stating the purpose of the change clearly
- assigning reviewers and work items properly
- following the rules of the target branch
This article covers Azure DevOps Services with Azure Repos and Azure Pipelines. Azure DevOps Server is left out here because Microsoft does not offer some newer review and AI features for it, or only plans them for later (Microsoft Learn, various pages, read or checked on 01/11/2026 and 24/10/2026).
Create a branch and push your changes
Start the branch where the change is described in business terms: usually on a work item. That keeps the link clear from the outset and helps you avoid catch-all branches with no clear purpose.
Create the branch from the branch the change is expected to go into later. In many teams that is main; for releases it is often a separate release branch. A consistent starting point reduces unnecessary differences in the comparison later on.
For the branch name, a simple, recognisable pattern is enough. These parts are especially helpful:
- type of change, for example feature, bugfix or hotfix
- short business or technical reference
- work item or ticket ID
Make the change in small, related commits and push the branch to Azure Repos as soon as it should be visible to others. Only then can the team build on it, for example for a joint review or further checks.
If you want to place the wider context around status, data flow and planned safeguards, you can find the current position on the page about Security and data. Planned sign-in and the subscription model are set out under Pricing and sign-up, and documented changes in the public changelog. Solid results belong separately on the page for measured evidence, which will remain empty until there have been real runs.
Open the pull request: title, description, reviewers, work items
Only open the pull request against the branch the change is actually meant to be merged into. That is what the applicable branch policies depend on. So the target branch determines not just the direction of the merge, but also the mandatory checks.
The title should make the change clear in a single sentence. The description should only add what cannot be reliably seen in the diff. Particularly useful are:
- the business purpose of the change
- affected areas in the repository
- assumptions or limits
- notes on what reviewers should pay particular attention to
Choose reviewers so that both subject matter knowledge and code ownership are covered. In Azure Repos, automatically included reviewers may also apply. This means people or groups that are added to pull requests automatically by a policy, for example for certain paths or components.
Also link the relevant work item. That keeps the connection to the requirement, defect or task visible in the pull request itself. If the linked work items policy is enabled on the target branch, this step is not just good housekeeping but one of the conditions for completion.
Microsoft lists these policy types for Azure Repos: minimum number of reviewers, linked work items, comment resolution, allowed merge types, build validation, status checks and automatically included reviewers; all are disabled by default (Microsoft Learn, “Branch policies overview” and “Branch policies”, read on 01/11/2026).
In practice, that means it is not the author of the pull request who decides what is sufficient, but the configuration of the target branch. Your team should define these rules deliberately, especially for main.
Use reviews, votes and comments sensibly
A pull request is not just read during review; it is assessed step by step. Votes and comment threads help with that. A vote is a reviewer’s explicit assessment of the current state of the pull request.
For day-to-day practice, the key point is this: votes always relate to the iteration in front of you. An iteration is a new state of the same pull request after further pushes. If new commits are added, an earlier approval may no longer hold from a technical or business point of view.
That is why your team should decide:
- when a fresh review is required after new pushes
- whether only the latest iteration needs approval
- whether existing approvals should be reset
- how to deal with “wait” or rejecting votes
These points can be reflected in Azure Repos policies. For the reviewer policy, Microsoft lists options including whether authors may approve their own changes, whether the person who pushed most recently may approve, and whether at least one approval on the latest iteration is required after new pushes (Microsoft Learn, “Branch policies”, read on 01/11/2026).
Keep questions and decisions in the pull request itself. That way it remains the reliable place for review context, instead of agreements being scattered across chat, ticket or meeting.
If you use additional automated reviews, keep their role clearly separate from formal approvals. For the public preview of Copilot code review in Azure Repos, Microsoft documents that this feature only ever leaves a Comment review. It therefore does not satisfy a Required reviewers policy and does not block a merge (Microsoft Learn, “Review pull requests” and “Review pull requests with Copilot code review”, read on 01/11/2026).
Complete the pull request: merge type, delete source branch, auto-complete
Before completing it, it is worth taking one final look at the consequences of the merge. At this point you are no longer deciding on the content of the change, but on how it will appear in the target history.
In Azure Repos, the merge type mainly governs the shape of the Git history. Git history means the visible order and structure of the commits that are brought in. Microsoft describes this setting as history governance, not as a direct security control (Microsoft Learn, “Securely use Git pull requests and branch policies to protect your important branches”, read on 01/11/2026).
For teams, these questions are usually the ones that matter most:
- Should the target history stay concise and easy to read?
- Must the exact commit sequence from the source branch be preserved?
- Should your audit model be based on individual commits or on the merged result?
A squash merge condenses the source branch into a single commit on the target branch. That can simplify the history. However, if your traceability depends on the exact commit sequence, Microsoft points to merge commit strategies rather than squash (Microsoft Learn, “Securely use Git pull requests and branch policies to protect your important branches”, read on 01/11/2026).
You can delete the source branch after completion if it has served its purpose. That keeps the branch list tidy and reduces the likelihood of someone later carrying on working on a branch that is already done.
Auto-complete is particularly suitable when the pull request is complete in terms of content, but completion is still waiting on checks that are outstanding. Azure DevOps will then complete it automatically as soon as the target branch conditions have been met.
Common team decisions: policies, security, data questions
In many teams, a clean pull request workflow does not fail because the pull request was not created, but because standards are unclear. So for critical target branches, define explicitly which evidence must be in place before completion and who, if anyone, is allowed to make exceptions.
For main, Microsoft lists the following among the sensible starting points:
- at least two reviewers
- automatically included reviewers for sensitive paths
- linked work items
- build validation
- resolved comments
- bypass permissions only for a small admin group
This comes from Microsoft Learn, “Securely use Git pull requests and branch policies to protect your important branches”, read on 01/11/2026.
If you are assessing additional AI features around pull requests, look at the data flow separately from usability. For Copilot code review, Microsoft documents that data residency is not tied to your Azure DevOps organisation’s data residency boundaries; processing may therefore take place in another geography despite EU hosting. Source: Microsoft Learn, “Copilot code review FAQ”, read on 01/11/2026.
As soon as source code, comments or metadata pass through additional services, the question is not only one of data protection but also of DORA, NIS2 and co-determination. Clarify this with your legal adviser or your data protection officer; this article does not constitute legal advice.
Frequently asked questions
Does every pull request have to be linked to a work item?
Not necessarily. Technically, you can create a pull request without a linked work item. The link only becomes mandatory if the linked work items policy is enabled on the target branch. Microsoft lists “Check for linked work items” as a separate branch policy; like the other policies, it is disabled by default (Microsoft Learn, “Branch policies overview” and “Branch policies”, read on 01/11/2026).
In practice, the link is especially helpful when other people later need to understand why the change was made.
Why can I see a pull request but not complete it?
In that case, rights are usually missing or mandatory evidence on the target branch is still outstanding. In Azure Repos, these rules may apply, among others:
- minimum number of reviewers
- build validation
- status checks
- resolved comments
- linked work items
In addition, Microsoft recommends for important branches that permissions to bypass policies should be given only to a small admin group (Microsoft Learn, “Securely use Git pull requests and branch policies to protect your important branches”, read on 01/11/2026).
Are branch policies enabled by default in Azure Repos?
No. Microsoft documents the policy types for Azure Repos, but also points out that they are switched off by default (Microsoft Learn, “Branch policies overview”, read on 01/11/2026).
For teams, that means: if you expect mandatory reviews, builds or status checks, you should check the configuration of the target branch rather than assume they are in place.
Can branch policies also be managed automatically?
Yes. Microsoft gives two ways to do this: the az repos policy commands and the REST API (Microsoft Learn, “Branch policies”, read on 01/11/2026).
This is particularly useful for teams that want to apply rules consistently across projects or manage policy changes in a traceable way.
Next step
What matters is less the act of opening the pull request than the question of what counts as evidence on the target branch. To answer that, your team should look in particular at these points:
- which policies are actually enabled on
mainand release branches - which status checks are purely informative and which are mandatory
- whether your review model fits the iteration logic of your pull requests
If you are observing automation in this workflow, keep a clear distinction between review hints, formal approvals and the merge itself.
Polier by ballmüller solutions, Berlin, is in development as of 01/11/2026 and is not available. It is intended for Azure DevOps Services to turn work items from Azure Boards into pull requests in Azure Repos; the customer’s branch policies apply, and the agent itself never merges.