Review pull requests
TFS 2018
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
- Vote on PR changes
Prerequisites
To view or review PRs, you must be a member of the Azure DevOps project with Basic access level or higher. If you aren't a project member, get added.
To learn more about permissions and access, see Default Git repository and branch permissions and About access levels.
Review changes
To give a quick picture of PR status, the PR Overview tab summarizes checks, requirements, and branch policies that the PR is passing or failing. In some cases, the summary shows a snippet of the failure message from a status check's log. The overview lists only failed policies, but you can see all the passed and failed policy checks by selecting View <n> checks.
On the PR Overview tab, you can review the PR description and comments to understand proposed changes and see issues other reviewers raised.
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
Add comments to a PR to make suggestions, reply to previous comments, and point out problems with the proposed changes.
Comment inline in the Files tab of a PR by hovering over the line you want to comment on and selecting the comment button
.
Give feedback not tied to a specific code line by commenting on the Overview tab.
Address the author or other reviewers directly in your comments by using
@username, and reference work items by using#workitemID. You can also reference other PRs by using!pullrequestID.
Like a comment
To like a comment that you or someone else made, select the heart icon. Hover over the icon in comments to see the list of people who liked the comment.
Filter comments
You can select which comments and updates show on the Overview tab. Hiding some comments and updates gets them out of the way when reviewing code for the first time. You can also show only what's new since the last time you visited the PR.
To filter comments and updates, select the Show everything (n) button above the comment list, and select one of the filtering options. The view changes to show only the selected comments and updates. The button label changes to show the filtering criteria and the number of items shown.
Address comments
You can make quick updates to your branch directly from the Files tab in Code on the web.
Reply and resolve comments
Reply to comments and update comment status to let reviewers know how you're addressing their comments and suggestions.
- To resolve a comment without replying, select Resolve under the comment.
- To reply to the comment, type your response in the Write a reply field, and select Reply.
- To reply to and resolve the comment, type your response in the Write a reply field, and select Reply & resolve.
- Reply to specific reviewers by using
@usernamein the reply, and reference work items by using#workitemID. You can also reference other PRs by using!pullrequestID.
New comments start in Active status. Select Resolve or Reply & resolve to update comment status to Resolved.
More options are available in the comment resolution dropdown list:
- Active: The comment is still under review.
- Pending: The issue in this comment will be addressed, but isn't fixed yet.
- Resolved: The issue brought up in this comment is fixed.
- Won't fix: The suggestion in the comment is noted, but this PR won't address it.
- Closed: Discussion for this comment is closed.
Vote on PR changes
Use the button at upper right in the PR to vote on the PR changes. The default option is Approve, but you can select other options from the dropdown list:
- Approve: Approve the proposed changes in the PR.
- Approve with suggestions: Approve the PR, but provide optional suggestions for improvement.
- Wait for author: Don't approve the changes, and ask the author to review your comments. The author should let you know to review the code again after they address your concerns.
- Reject: The changes aren't acceptable. Leave a comment in the PR to explain why.
- Reset feedback: Remove your vote.