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.
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.
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.
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.
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 S