Merge Conflict Resolver for Azure DevOps

Yes. Merge Conflict Resolver is an independent, actively maintained alternative to the Pull Request Merge Conflict Extension from Microsoft DevLabs, which is no longer maintained. It adds the same kind of Resolve conflicts tab to the pull request, with a 3-way editor, per-conflict and per-line choices, crash-safe drafts and, with Pro, an Update branch button, and it works on Azure DevOps Services and Azure DevOps Server 2022 or later. There is a free plan (10 pull requests per organization per month, with all editor features and conflict types). If you prefer not to use an extension, you can merge the target branch into the source branch locally in Visual Studio, VS Code or any merge tool and push. Merge Conflict Resolver is not affiliated with Microsoft.

You can, and for a big refactoring you probably should. But for the everyday conflict in a changelog, a config file or a lockfile, a local merge means fetching both branches, merging, resolving, committing and pushing, and not every reviewer, tester or product owner has a clone and a merge tool at hand. Here anyone with access to the pull request resolves it in the browser, in a minute, and with Pro the result lands on the source branch exactly like a local merge.

No. One license covers the whole Azure DevOps organization, and its tier sets how many people may use it (25, 100 or unlimited). Anyone with access to the repository can use it; what they can change is decided by their own Azure DevOps permissions.

Unsaved drafts stay in your browser's local storage until you resolve or discard them. The license, trial date and free-plan counter are stored in your organization's own extension data storage. Nothing is sent to us; see the privacy policy.

Azure DevOps Services (dev.azure.com), and Azure DevOps Server 2022 or later (on-premises). Older versions (2020, 2019, TFS) are not supported. See Azure DevOps Server for install steps and licensing.

A pull request counts once per calendar month, the first time someone in your organization saves a resolution in it. Opening the tab or looking at conflicts doesn't count. After 10 pull requests, you can still view conflicts, but new pull requests can only be resolved with Pro until the next month.

The organization falls back to the free plan. Nothing breaks, and resolutions and commits you made stay as they are. You can buy Pro at any time to continue.

Yes. Resolving conflicts doesn't bypass policies: you still complete the pull request as usual. Commit to <source branch> pushes a new commit to the source branch, so your policies apply to it like any other push; if the branch is set to reset votes on new pushes, approvals are reset. If a policy blocks direct pushes to the source branch, the commit is refused with a clear message and your resolutions stay in the pull request.

Azure DevOps creates it, the same way it creates the merge for any pull request, with the message “Merge pull request … from … into …”. With Commit to <source branch>, that commit is added to the source branch as is.

Yes, with Pro. Under Resolution rules in the extension settings you map a file pattern to take target, take source or keep both, for example package-lock.json to the target. In the Resolve conflicts tab you apply the matching rules to a pull request in one click; files you already started on are left alone.

Yes, with Pro. When a pull request has no conflicts but the target branch has moved on, the Resolve conflicts tab shows how many commits the source is behind, with an Update branch button. After you confirm, the source branch is fast-forwarded to the merge commit Azure DevOps prepared for the pull request (target merged into source), the same result as git merge and a push. Your branch policies apply to that push like to any other, and it is refused if someone pushed in the meantime.

It only resolves conflicts where both sides added lines to the same list: imports and usings (C#, TypeScript and JavaScript, Python, Java and Kotlin, Go, C and C++), dependencies in package.json, PackageReference items in a project file, and entries in CHANGELOG.md. Both additions are kept, without duplicates and in sorted order if the list was sorted. The same package with two different versions, a removed or changed line, or anything else it isn't sure about stays a conflict. You see the result before you save, and Ctrl+Z undoes it.

They can't be merged line by line, so you choose which version to keep. For Git LFS files the choice is made on the LFS pointer, so the stored file itself is never touched.

• Conflicts of cherry-pick and rebase operations aren't supported: Azure DevOps doesn't offer conflict resolution for those, so no extension can.
• Commit to <source branch> and Update branch aren't available for pull requests from a fork, because the source branch lives in another repository.
• Binary files and Git LFS files can't be merged line by line; you choose which version to keep.

Yes. See the release notes for what changed recently. Questions and bug reports get an answer within 2 business days; see the support policy.

Your code, pull requests and settings live in Azure DevOps, so there is nothing to migrate. If development of the extensions ever stops, they will be made open source and handed over to another maintainer, so your team can keep using them.