Review pull requests

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

When you create a pull request (PR) and specify required/optional reviewers, Azure Repos will notify 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 the main branch, your team might have created 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.

If you're reviewing a PR, try to give constructive feedback that's precise and easy to understand. For more information on review feedback, see Pull request feedback. This article describes how to review pull requests in Azure DevOps.

You can only review Azure DevOps PRs in the web portal by using your browser.

In this article you learn how to:

• Review changes
• Use comments
• Edit files
• Track reviewed files
• Vote on PR changes
• Complete a PR

Prerequisites

• Repos must be enabled in your Azure DevOps project settings. If the Repos hub and associated pages don't display, see Turn an Azure DevOps service on or off to reenable Repos.

• To review PRs, you must be a member of the Azure DevOps project the PR is in, with Basic access level or higher.

  • If you don't have a project, create one or sign up for free.

  • If you aren't a project member, get added.

  Note

  For public projects, users granted Stakeholder access have full access to Azure Repos.

• To learn more about permissions and access, 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 are applied to a target branch of a repo. Keep in mind that if development is carried out with the same files on different branches there may be a conflicting changes. In that case it is required to carefully analyze and resolve those conflicts. To do so, may require manually editing the file to correctly apply the changes from either source, target or both branches. Taking all changes from either source or target (which can be done by a single button click) may not be optimal and can result in loss of some required changes. This can be done using ADO tools, or it will be more convenient to use development tools (such as Visual Studio).

To learn more see Resolve merge conflicts.

The following steps describe how reviewers of PRs in Azure Repos can navigate through a PR to understand the proposed changes:

1. From your web browser, open the team project for your Azure DevOps organization. Choose Repo > Pull requests to list the PRs. A newly opened PR defaults to the Overview tab.

2. The Overview tab of a PR shows the title, description, reviewers, linked worked 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 estimated for a number of modifications and is marked with a "+" sign or a "rename, edit" label next to its name. When a file has more than 50-percent changes, it is considered renamed. This is the default threshold for git repositories that cannot be changed.

   

3. 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 won't show changes for a file that's larger than 0.5 MB.

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

5. 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 have been 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.

6. Choose the Updates tab to view all pushed changesets to ensure you haven't missed 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 won't overwrite the changeset history and will show up in the changeset list same as any other changeset.

   

7. 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 will be 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.

   

Review files

Select the PR Files tab to view the actual changes made to the source branch next to the target branch of the pull request.

Note

The different changes between Azure DevOps Pull request and Azure DevOps Branch compare is caused by the different comparison methods.

There are two comparison methods for git diff command: Two-dot (git diff A..B) and three-dot (git diff A...B). By default, Pull Requests show a three-dot diff while the Branch Comparison instead shows a two-dot diff.

For example:

      C---D---E branch
     /
A---B---F---G   master

Pull Requests: git diff branch...master will produce only C, D, E commits. Branch Compare: git diff branch..master will produce C, D, E, F, G commits.

For more details, see three-dot-and-two-dot-git-diff-comparisons and git diff

Note

When viewing the difference for a single selected file, there's a file size limit of 5 MB. To view and diff files larger than 5 MB, you can download the file and view it using a local diff tool. When viewing the difference for a collection of files, the size limit for each file is 0.5 MB, for performance reasons.

Review updates

Review previous versions of the code from the All updates drop-down list.

Every update to the branch adds a new version to the list and on the Updates tab of the PR. As you select different updates, the diff view updates to show the differences between the files in each version of the PR.

You can catch up with PR updates after being away from the PR by stepping through changes made since your last review.

Browse a list of changes from the author on the Updates tab.

View and select changes made in commits to the branch on the Commits 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 issues 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:

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

   

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

You can use comments to suggest replacement text for one or more lines in a file:

1. 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 will replace the line or lines that your comment was added to.

   

2. 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 won'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:

1. Choosing Apply changes to stage the change in readiness for a commit.

   

2. Choosing Commit all changes to commit all staged changes. PR authors can unstage a suggestion by choosing Undo change.

   

Edit or delete comments

You can 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:

1. 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 #workitemID and other PRs by using !pullrequestID.

   

2. After entering your response, select Reply & resolve if your response is final. Otherwise, select Reply.

   

   If you select Reply & resolve, the comment status will change to Resolved. PR authors can also directly change a comment's status, as described in the next section.

Change comment status

New comments initially have an Active status, which PR authors update during PR 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 have accepted a reviewer's suggested code change and want to make similar changes elsewhere.

1. Choose Repos > Files, select the PR source branch, select a file, and then choose Edit.

   

2. Make your changes in the editor, and then choose Commit to open the Commit dialog.

   

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

Browser

PR reviewers can vote on a PR by selecting a vote option from the vote dropdown list. The reviewer icon on the PR page will show an indication of their vote.

The voting options are:

• Approve: approves the proposed changes in the PR. This option is just a vote and doesn't approve the PR.

• Approve with suggestions: approves the proposed changes in the PR with optional suggestions for improvement. This option is just a vote and doesn't approve 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 the PR author has addressed the comments. If a required reviewer sets this vote option, the vote will block 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 vote option, the vote will block PR approval.

• Reset feedback: clears your vote. The absence of a vote doesn't prevent a PR from being completed.

Azure DevOps CLI

To vote on whether to approve a PR, use the az repos pr set-vote command.

az repos pr set-vote --id
                     --vote {approve, approve-with-suggestions, reject, reset, wait-for-author}
                     [--detect {false, true}]
                     [--org]
                     [--subscription]

Parameters

Parameter	Required	Description
--id	Yes	Pull request ID
--vote	Yes	New vote value for the pull request (accepted values: approve, approve-with-suggestions, reject, reset, or wait-for-author)
--detect	No	Automatically detect organization (accepted values: false, true)
--organization	Yes, if a default org isn't set and the git config file doesn't specify the org	Azure DevOps organization URL, or set a default org using: az devops configure -d organization=<organization URL>
--subscription	No	Name or ID of an Azure subscription, or set a default subscription using: az account set -s <name or ID>

Examples

The following command will vote to approve PR #21. The command returns a table.

az repos pr set-vote --id 21 --vote approve --output table

Name            Email                ID                                    Vote      Required
--------------  ------------------- -------------------------------------  --------  ----------
Jamal Hartnett  jamalh@fabrikam.com  00000000-0000-0000-0000-000000000000  Approved  False

The following command removes your vote. The command returns a table.

az repos pr set-vote --id 21 --vote reset --output table

Name            Email                ID                                    Vote      Required
--------------  ------------------- -------------------------------------  --------  ----------
Jamal Hartnett  jamalh@fabrikam.com  00000000-0000-0000-0000-000000000000            False

Complete a PR

PR authors can select a PR resolution option:

• Complete: complete the PR now if all required reviewers have 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 indicates it's not ready for review. For a draft PR, you can select Publish to remove its draft status and mark it ready for review.

• Abandon: close the PR. For an abandoned PR, you can select Reactivate to restore it.

For more information on completing a PR, see Complete the pull request.

Next steps

Complete the pull request

Related articles

• Pull request update notifications
• About pull requests and permissions