How To Create Pull Request In Azure DevOps

In this article, I will walk you through exactly how to create, manage, and complete a pull request in Azure DevOps. I will cover the technical steps via the web portal, Visual Studio, and the command line, and I will also dive deep into the branch policies and merge strategies.

Table of Contents

How to Create Pull Request in Azure DevOps

How to Create Pull Request in Azure DevOps

What is a Pull Request in Azure DevOps?

At its core, a pull request is a formal proposal to merge code from a “source” branch (where you did your work) into a “target” branch (usually main or develop).

However, in the context of Azure DevOps, a PR is much more than that. It acts as a gatekeeper. It is the specific moment in the software lifecycle where:

Code Review happens (humans checking logic).
CI/CD Triggers fire (robots checking syntax and tests).
Compliance is logged (linking code to tickets like Jira or Azure Boards).

Prerequisites: Before You Click “Create”

To follow this tutorial, you need:

Access Rights: You must have Basic access level or higher in your Azure DevOps organization. Stakeholders usually cannot write code or create PRs.
A Feature Branch: You should never commit directly to main. You need a branch (e.g., feature/login-page) that is ahead of the target branch.
Committed Changes: Your local changes must be pushed to the remote repository in Azure Repos.

Method 1: Creating a PR via the Web Portal

This is the method I recommend for 90% of users. The web portal offers the most visibility into what is actually happening with your code.

Step 1: Navigate to Pull Requests

Log in to your Azure DevOps organization (dev.azure.com/your-org). Go to your project, then select Repos > Pull requests from the left-hand navigation bar as shown in the screenshot below.

How to Create Pull Request in Azure DevOps

Step 2: The “New Pull Request” Button

If you just pushed code to a branch, Azure DevOps is usually smart enough to show a banner saying, “You updated feature/new-api just now. Create a pull request.” If you see that, click it. If not, click the blue New pull request button in the top right corner, as shown in the screenshot below.

how to create a pull request in azure devops

Step 3: Configure the Source and Target

This is where mistakes happen. You will see two dropdowns:

Source branch: Select the branch you worked on (e.g., feature/update-dashboard).
Target branch: Select where the code is going (e.g., main). Check out the screenshot below for your reference.

Pro Tip: I always double-check the “Files” tab at this stage. If you see 0 files changed, you probably selected the wrong branches or haven’t pushed your latest commit.

Step 4: Flesh Out the Details

You will be presented with a form. Do not leave this blank. A blank PR description is a signal of laziness to your reviewers.

Title: Make it descriptive. Instead of “Fix bug,” use “Fix: Login timeout issue on West Coast servers.”
Description: Explain what you changed and why. I usually add a section called “Testing Done” to prove I ran the code locally.
Reviewers: Search for your team members. For example, if I know Sarah is the lead on the database schema, I will explicitly add her here.
Work Items: This is critical. Link the User Story or Bug from Azure Boards. This ensures that when the boss looks at the ticket later, they can see exactly what code fixed it.

Step 5: Create

Click Create. Your PR is now live.

Method 2: Creating a PR via Visual Studio

If you are a .NET developer living inside Visual Studio, you don’t need to leave your IDE. I find this workflow faster when I am in the “zone.”

Open Team Explorer: Go to the Git Changes window.
Push Your Branch: Ensure your latest commits are synced.
Click “Create Pull Request”: In newer versions of Visual Studio (2022+), there is often a direct link in the Git notification bar after a push.
Browser Handoff: interestingly, Visual Studio often opens your default web browser to finish the details (Title, Description) because the web UI is simply better for entering rich text.

Check out the screenshot below for your reference.

Method 3: The Command Line

I work with many Linux-based engineers who hate leaving the terminal. Azure DevOps has a powerful CLI extension that handles this beautifully.

Assuming you have the Azure CLI installed (az), the syntax is straightforward. You don’t need to memorize the arguments, but you should know the capability exists.

The command az repos pr create allows you to define the source, target, title, and description all without touching a mouse. I find this incredibly useful for scripting automated PRs—for example, if you have a bot that updates dependencies automatically.

Critical Component: Understanding Branch Policies

You might click “Create,” but you might notice you cannot click “Complete” or “Merge” yet. That is likely due to Branch Policies.

Here is a breakdown of the policies you will likely encounter:

Policy Type	What it Does	Why We Use It
Minimum Number of Reviewers	Requires at least 1 or 2 people to click “Approve.”	Prevents “rogue merging” where a dev merges their own code without oversight.
Check for Linked Work Items	Blocks the PR if no ticket is linked.	Ensures every code change is tied to a business requirement or bug.
Build Validation	Triggers a CI pipeline (build & test) automatically.	If your code compiles on your machine but breaks the build server, this policy stops you.
Comment Resolution	Requires all comments to be marked “Resolved.”	Ensures you didn’t just ignore Sarah’s feedback about that potential security flaw.

If your “Complete” button is grayed out, look at the top left of the PR page. It will list exactly which policy is failing (e.g., “Waiting for Build” or “1 Reviewer Required”).

Troubleshooting Common Issues

Even the best engineers run into walls. Here are the most common issues I see when creating PRs in Azure DevOps.

“I have Merge Conflicts”

This means someone else (maybe John from the New York team) changed the exact same lines of code you did, and they merged their PR first.

The Fix: You need to pull the latest main into your branch and resolve the conflicts locally. Azure DevOps has an online conflict resolution tool (the “Conflicts” tab), but I strongly advise doing this locally in VS Code or Visual Studio where you have better tools.

“The Build Pipeline Failed”

You created the PR, but the “Checks” section has a red X.

The Fix: Click the “View details” link next to the failure. 99% of the time, it’s a unit test failure or a linting error. Do not ask for a review until this is green.

“I Can’t Add a Specific Reviewer”

The Fix: They might not be in the project. Check with your Project Administrator. Alternatively, check if you are trying to add a group that you don’t have permission to view.

Frequently Asked Questions (FAQ

Q: Can I edit a Pull Request after creating it?

A: Yes, absolutely. You can update the title, description, and even push new code to the source branch. The PR will automatically update with the new commits.

Q: What is the difference between “Draft” and “Publish”?

A: A Draft PR allows you to open the request without notifying reviewers immediately. This is great if you want to see the build results or check for merge conflicts before officially asking for a review.

Q: How do I delete a Pull Request?

A: Technically, you “Abandon” a PR in Azure DevOps. You generally cannot permanently delete the record of it (for audit reasons), but abandoning it removes it from the active queue.

Q: Why is the “Complete” button grayed out?

A: This is almost always due to a Branch Policy. Check the top left of the PR overview to see which policy is not satisfied (e.g., missing reviewer, failed build, or unresolved comments).

Q: Can I merge a PR with failed tests?

A: Only if you have “Bypass Policy” permissions, which are usually reserved for Admins or Principal Engineers. Doing this is generally frowned upon unless it is a critical emergency hotfix.

Conclusion

Creating a pull request in Azure DevOps is a straightforward process, but knowing the workflow is what leads to high-performing teams. It is about more than just merging code; it is about respecting the process of quality assurance and collaboration.

You may also like the following articles:

Rajkishore

I am Rajkishore, and I am a Microsoft Certified IT Consultant. I have over 14 years of experience in Microsoft Azure and AWS, with good experience in Azure Functions, Storage, Virtual Machines, Logic Apps, PowerShell Commands, CLI Commands, Machine Learning, AI, Azure Cognitive Services, DevOps, etc. Not only that, I do have good real-time experience in designing and developing cloud-native data integrations on Azure or AWS, etc. I hope you will learn from these practical Azure tutorials. Read more.