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