You can resolve merge conflicts in Azure Repos directly in the pull request or locally in your Git client. For small, clear-cut text conflicts, the browser is often enough; if several files are involved, files have been renamed, or tests are needed, resolving them locally is usually the better option. Afterwards, the pull request must meet the active branch policies again.
A merge conflict arises when Git cannot unambiguously combine changes from the source and target branches. This often affects the same part of a file or closely related changes.
This article is aimed at teams using Azure DevOps Services, Azure Repos and Azure Pipelines. It helps you decide between resolving conflicts in the browser and doing so locally.
If you want to define your team’s process around conflicts clearly, a PR template, draft pull requests and a guide to creating a pull request are a good fit.
Why conflicts arise in Azure Repos
Conflicts arise when Git can no longer combine two changes into a single version with certainty. In Azure Repos, this typically happens when the source and target branches have both moved on in the meantime in the same places or in closely related files.
Typical triggers are:
- the same file has been edited in both branches
- a file has been renamed or moved while its content was changed in parallel
- imports, signatures or interfaces were adjusted at the same time
- a larger refactoring took place alongside functional changes
- formatting changes affected many lines
A refactoring is a structural change to code without changing the intended business function.
For the team, one point matters in particular: a merge conflict is not in itself a sign of poor code. Above all, it shows that several changes have collided in time and technically. The further a feature branch diverges from the target branch, the more likely Git is to reach the limits of automatic merging.
Your chosen merge strategy also shapes how often conflicts become visible and how easy they are to trace later. According to Microsoft Learn, the Azure Repos setting Limit merge types governs history more than it serves as a direct security function. If the exact commit sequence matters to you, you should assess merge strategies deliberately.
Resolving in the browser: when that is enough
Resolving a conflict in the pull request in the browser is suitable when the conflict is small, clear and immediately understandable. This applies above all when only a few text files are affected and you can determine the intended final version with confidence without needing additional project context.
In practice, the browser is especially useful in these cases:
- only isolated conflict points rather than a chain of related changes
- no renames, moves or generated files
- no binary files
- no decision that can only sensibly be checked after a local build
A binary file is a file whose contents cannot sensibly be merged line by line as text.
The browser is less suitable if you need to jump between several files while reading, suspect side effects, or only tests will make things clear. In those cases, resolving the conflict in the pull request often takes more concentration than comparing the changes locally.
A simple team rule is therefore helpful: use the browser only for manageable text conflicts, and resolve anything with technical risk locally. That helps you avoid a situation where the conflict disappears formally, but the real decision remains unchecked.
For teams that also want to document these processes, it is worth keeping topics clearly separate: questions about data protection, data paths, identities and guardrails belong on the page about Security and data. Preliminary details about sign-up and the subscription model can be found under Pricing and sign-up. Real measured values belong later in the section for measured results. Changes to the product status and scope of features are best tracked in the public changelog.
Resolving locally: merge or rebase the target branch
As soon as a conflict affects several files or only makes sense with the project context running locally, resolving it locally is usually the cleaner approach. That also applies to renames, moves and cases where you can only assess the change reliably after a build and tests.
When bringing in the target branch, you have two patterns:
- Merge brings the current state of the target branch into your working branch.
- Rebase reapplies your own commits on top of the newer state of the target branch.
The difference mainly affects the commit history. A commit history is the traceable sequence of changes in Git. Merge preserves the existing sequence, while rebase rewrites it for the source branch.
That is why merge is often more suitable if a branch is already used by several people or commits have already been shared. Rebase is more suitable if you control the branch yourself and want to keep a straight-line sequence of your commits.
For Azure Repos, one point is important here: which completion types are permitted in a pull request at all is defined by the Limit merge types policy; source: Microsoft Learn “Branch policies overview” and “Branch policies”, accessed on 01.11.2026.
Microsoft also classifies this setting as a control for history rather than a direct security function. If the exact commit sequence matters to your team for traceability or internal review paths, you should choose merge or rebase with that in mind; source: Microsoft Learn “Secure repositories in Azure Repos and Azure Pipelines”, accessed on 01.11.2026.
After resolving locally, these points matter most before you push:
- remove all conflict markers completely
- review the result from a business perspective
- run the build and tests locally
- only then push the updated branch
After that, expect a new pull request iteration. This can reset approvals, require new approvals on the latest iteration, and trigger pipelines or status checks again; source: Microsoft Learn “Branch policies”, accessed on 01.11.2026.
Avoiding conflicts: small branches, integrate frequently
The most effective way to avoid merge conflicts is both organisational and technical: keep changes small, do not leave branches open longer than necessary, and integrate with the target branch regularly. The shorter the time between change and integration, the smaller the difference Git usually has to merge later.
In practice, these patterns help most:
- several small pull requests instead of one large catch-all branch
- refactorings kept separate from functional changes
- coordinate formatting waves, renames and moves deliberately
- make changes to heavily used files visible early
For teams using Azure Pipelines, frequent integration is particularly worthwhile when build validation is active. Errors and side effects then become visible closer to the change that caused them, rather than only after many more commits; source: Microsoft Learn “Branch policies overview” and “Secure repositories in Azure Repos and Azure Pipelines”, accessed on 01.11.2026.
Draft pull requests are also helpful. They make a change visible to the team early, even if it is not yet finished, and the branch is then less likely to drift far from the target branch in business or technical terms. A draft is a pull request that can already be discussed, but is not yet intended as a final review candidate.
How the work is organised is just as important. If several people are working on adjacent areas, clear agreements on sequence, responsibilities and interfaces often reduce the likelihood of conflicts more than any tool can.
Automatically included reviewers for sensitive paths do not resolve conflicts directly. But they make affected areas visible earlier and support consistent review decisions; source: Microsoft Learn “Secure repositories in Azure Repos and Azure Pipelines”, accessed on 01.11.2026.
Automatic code review will not resolve conflicts for you either if a pull request is already in a conflicted state. According to Microsoft, Copilot in Azure Repos reviews only active, conflict-free pull requests; source: Microsoft Learn “Copilot code reviews”, accessed on 01.11.2026.
Common questions about resolving merge conflicts
Does my pull request stay the same when I resolve the conflict?
Yes, as a rule it remains the same pull request. You are not creating a new process; you are providing another iteration of the same change. That matters for reviews because the basis for assessment has changed.
In practice, this means:
- comments may become relevant again
- checks often run again
- approvals may change their status depending on policy
Why can I often still not complete it even though the conflict is resolved?
The conflict is only one part of the path to completion. In Azure Repos, whether a pull request may be completed is determined by the active branch policies.
In “Branch policies overview” and “Branch policies”, accessed on 01.11.2026, Microsoft lists, among other things, these policies:
- minimum number of reviewers
- linked work items
- resolved comments
- build validation
- status checks
- automatically included reviewers
If one of these conditions is open again after the conflict has been resolved, completion remains blocked.
What happens to existing approvals after a new push?
That depends on the reviewer policy. According to Microsoft Learn “Branch policies”, accessed on 01.11.2026, Azure Repos can handle approvals in different ways when new pushes are made.
Possible settings include, for example:
- requiring at least one new approval on the latest iteration
- resetting all approvals
- resetting all reviewer votes
- not allowing the last person who pushed to count as the approving person
Especially after resolving conflicts, you should therefore check which rule your target branch actually uses.
Is a conflict a sign of a problem in the repository?
Not automatically. A conflict initially only shows that Git could not safely merge two changes by itself. That is normal when people are working in parallel.
It becomes more noticeable if conflicts repeatedly occur in the same places, for example with:
- long-lived open branches
- large bundled changes
- parallel refactorings
- frequently changed interfaces
In that case, it is often less useful to look for an individual error than to review how the team’s work is structured.
Next step
Set a fixed approach to conflicts for your team instead of improvising each case anew. What matters less is the tool than a clear expectation: who resolves the conflict, who reviews the substantive decision, and when a change is considered ready for review again after a new iteration.
Three points are sensible here:
- separate responsibility for conflict resolution and business review
- plan fixed reviewers for sensitive areas
- after every conflict resolution, check the PR again for open comments, builds and status
If you later assess the use of AI-supported development in Azure DevOps Services, that also includes questions of data protection, DORA, NIS2 and co-determination. Clarify this with your legal adviser or data protection officer. Polier is in development and not available as of 01.11.2026.