Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022
Tip
You can use AI to help with Azure DevOps tasks. See Enable AI assistance with Azure DevOps MCP Server to get started.
When you create a pull request (PR) and specify required and optional reviewers, Azure Repos notifies the reviewers that your PR is ready for review. All required reviewers must approve the changes in your PR before the changes can merge into the target branch. For PRs that change critical branches like main, your team might have branch policies that specify the reviewers or require a minimum number of reviewers. If branch policies add optional reviewers to your PR, you can keep them, require them, or remove them. If branch policies add required reviewers to your PR, you can't make them optional or remove them. For information about assigning reviewers through branch policies, see Automatically include code reviewers.
When you review a PR, give constructive feedback that's precise and easy to understand. For more information, see Pull request feedback.
You can only review Azure DevOps PRs in the web portal by using your browser.
Prerequisites
| Category | Requirements |
|---|---|
| Project | An Azure DevOps project. If you don't have a project, create one or sign up for free. |
| Services | Repos enabled in your project. If the Repos hub doesn't display, see Turn an Azure DevOps service on or off. |
| Access levels | At least Basic access. For public projects, users with Stakeholder access have full access to Azure Repos. |
| Permissions | Membership in the Azure DevOps project that contains the PR. If you aren't a project member, get added. For more information, see Default Git repository and branch permissions and About access levels. |
| Category | Requirements |
|---|---|
| Services | Repos enabled in your project. If the Repos hub doesn't display, see Turn an Azure DevOps service on or off. |
| Access levels | At least Basic access. |
| Permissions | Membership in the Azure DevOps project that contains the PR. If you aren't a project member, get added. For more information, see Default Git repository and branch permissions and About access levels. |
You can manage PRs in Azure DevOps Services by using the Azure DevOps command line interface (CLI). The Azure DevOps CLI is available when you install the Azure CLI and the Azure DevOps extension. For a list of CLI commands to manage PRs, see the az repos pr commands.
Review changes
Pull requests let designated reviewers examine, discuss, and vote on proposed changes before those changes merge into a target branch. If the same files are changed on both the source and target branches, you might see merge conflicts. Carefully analyze conflicts and edit the files manually to apply the right changes from each branch. Taking all changes from only the source or only the target with a single click can cause you to lose required changes. You can resolve conflicts in Azure DevOps or in a development tool like Visual Studio.
For more information, see Resolve merge conflicts.
Request a Copilot code review
You can ask GitHub Copilot to review a pull request alongside human reviewers. Copilot posts comments and suggestions directly on the changed code, so you can address common issues before a human reviewer signs off.
To request a review, open a pull request and select Request next to GitHub Copilot in the Reviewers section. Copilot always leaves a Comment review, so its feedback doesn't satisfy required-reviewer policies and doesn't block merging.
This feature is in limited public preview and requires sign-up. For setup, billing, and limits, see Get started with Copilot code review for pull requests.
Review changes as a human reviewer
The following steps describe how reviewers of PRs in Azure Repos can navigate through a PR to understand the proposed changes:
From your web browser, open the team project for your Azure DevOps organization. Choose Repos > Pull requests to list the PRs. A newly opened PR defaults to the Overview tab.
The Overview tab of a PR shows the title, description, reviewers, linked work items, history, status, and comments. Read the PR description to see the proposed changes. View the comments to understand the issues raised by other reviewers.
Note
Each file is marked with a "+" sign or a "rename, edit" label next to its name to indicate the type of change. When a file has more than 50 percent changes, Git considers it renamed. This threshold is the default for Git repositories and can't be changed.
Select the Files tab to review all content changes in the PR's source branch. The initial view shows a summary view of all file changes. Choose the View button next to a file to view only that file's changes. If the file was modified, the View button opens a diff view. If the file was added or deleted, the View button opens a content pane.
Note
For performance reasons, the summary view doesn't show changes for a file that's larger than 0.5 MB.
In a diff view for a file, you can select either a Side-by-side or Inline diff layout.
Tip
For any single file that's larger than 5 MB, the diff view shows truncated file content. For a diff view of the full content, download and review such files by using a local diff tool.
Use the left-hand file tree to view another file, or select the root of the file tree to see a summary view of all file changes.
To review the changeset introduced by specific pushes to the source branch, select one or more changesets from the changes dropdown list. When you select one or more changesets, the diff view updates to show only the changes from the selected changesets. This feature is useful when changes are pushed to the PR since your last review and you just want to see the new changes. The changes dropdown list names each changeset with the commit message from the final commit in each push operation.
Tip
Hold the Shift key when selecting multiple changesets from the changes dropdown list.
Choose the Updates tab to view all pushed changesets and to confirm you didn't miss any source-branch changes. The changesets are numbered and the most recent changeset appears at the top of the list. Each changeset shows the commits that were pushed in that push operation. A force-pushed changeset doesn't overwrite the changeset history and appears in the changeset list like any other changeset.
Choose the Commits tab to view the commit history of the source branch after it diverged from the target branch. The commit history in the Commits tab is overwritten if the PR author force-pushes a different commit history, so the commits shown in the Commits tab might differ from the commits shown in the Updates tab.
Use comments
PR authors and reviewers can communicate with each other by adding and responding to PR comments. When you review a PR, use comments to point out problems with the proposed changes, suggest changes, and respond to previous comments. Aim for constructive feedback that's precise and easy to understand. Address recipients directly by using their @username. Reference work items by using #workitemID and other PRs by using !pullrequestID. Sometimes, PR authors create comments for themselves for documentation purposes.
Provide feedback in comments
If your feedback applies to a specific line or range of lines in a file, add a comment at that location within the file:
In the Files tab of a PR, hover over the line you want to comment on and select the comment button
to open an inline comment box. You can also select multiple lines and then select the comment button that appears when you hover over those lines.Enter your comment in the comment box and choose Comment.
If your feedback applies to the entire file, add a file-level comment by selecting Add comment from the file options menu:
To provide general feedback unrelated to a specific file, add a comment in the Overview tab:
PR reviewers can also use comments to suggest changes to specific file lines, as described in the next section.
Suggest changes in comments
Use comments to suggest replacement text for one or more lines in a file:
In the Files tab of a PR, hover over the line you want to comment on and select the comment button
to open an inline comment box. You can also select multiple lines and then select the comment button that appears when you hover over those lines. If accepted, your suggested content replaces the line or lines that your comment was added to.Select the light bulb icon under the comment box to make your suggested changes in the comment box within a fenced code block, and then choose Comment. You don't see a light bulb icon if you add a comment to the original code (left-hand side) of a side-by-side diff view.
PR authors can accept your suggestion by:
Choosing Apply changes to stage the change in readiness for a commit.
Choosing Commit all changes to commit all staged changes. PR authors can unstage a suggestion by choosing Undo change.
Edit or delete comments
Edit or delete your comment by hovering over the comment and choosing the edit or delete icon:
Like comments
PR authors and reviewers can like their own or someone else's comment by hovering over the comment and choosing the thumbs-up icon:
Comments with likes show a filled-in thumbs-up icon and the number of likes. Hover over the thumbs-up icon to see the list of people who liked the comment.
Reply to comments
PR authors should reply to comments to let the reviewers know how they're addressing feedback and suggestions:
To reply to a comment, type your response in the Write a reply field. Address recipients directly by using their
@username. Reference work items by using#workitemIDand other PRs by using!pullrequestID.
After entering your response, select Reply & resolve if your response is final. Otherwise, select Reply.
If you select Reply & resolve, the comment status changes to Resolved. PR authors can also directly change a comment's status, as described in the next section.
Change comment status
New comments start with an Active status. PR authors update the status during the review process to indicate how they addressed reviewer feedback and suggestions. PR authors can select a comment status from the status dropdown list:
- Active: The default status for new comments.
- Pending: The issue in this comment is under review and awaits something else.
- Resolved: The issue in this comment is addressed.
- Won't fix: The issue in this comment is noted but won't be fixed.
- Closed: The discussion in this comment is closed.
PR authors and reviewers can track PR progress by filtering on comment status, as described in the next section.
Filter comments
You can select which comments or updates show on the Overview tab by selecting a filter option from the comment filter dropdown list. For example, select the What's new filter option to see new comments and updates since you last opened the PR. Each filter option shows the number of items for its category.
Edit files
For convenience, PR authors can edit files directly in Azure Repos. For example, you might accept a reviewer's suggested code change and want to make similar changes elsewhere.
Select Repos > Files, select the PR source branch, select a file, and then choose Edit.
Make your changes in the editor, and then choose Commit to open the Commit dialog.
In the Commit dialog, edit the commit message if necessary, and then choose Commit to commit and push the changes to your PR.
Track reviewed files
PR reviewers can keep track of reviewed files by choosing Mark as reviewed from the file options menu, or by selecting the checkbox next to a file or folder:
Vote on PR changes
PR reviewers can vote on a PR by selecting a vote option from the vote dropdown list. The reviewer icon on the PR page indicates the vote.
The voting options are:
- Approve: Approves the proposed changes in the PR. This option is a vote and doesn't complete the PR.
- Approve with suggestions: Approves the proposed changes with optional suggestions for improvement. This option is a vote and doesn't complete the PR.
- Wait for author: Asks the author to review the reviewer comments. The PR author should let the reviewers know to re-review the code after they address the comments. If a required reviewer sets this option, the vote blocks PR approval.
- Reject: Indicates that the changes aren't acceptable. When you choose this option, add a comment explaining why. If a required reviewer sets this option, the vote blocks PR approval.
- Reset feedback: Clears your vote. The absence of a vote doesn't prevent a PR from being completed.
Complete a PR
PR authors can select a PR resolution option:
- Complete: Complete the PR now if all required reviewers approved it and all required branch policies are met.
- Set auto-complete: Auto-complete the PR when all required reviewers approve it and all required branch policies are met.
- Mark as draft: Set the PR to draft status to indicate it isn't ready for review. For a draft PR, select Publish to remove draft status and mark it ready for review.
- Abandon: Close the PR. For an abandoned PR, select Reactivate to restore it.
For more information, see Complete the pull request.