About reviewing pull requests
You can review changes in a pull request one file at a time. While reviewing the files in a pull request, you can leave individual comments on specific changes. After you finish reviewing each file, you can mark the file as viewed. This collapses the file, helping you identify the files you still need to review. A progress bar in the pull request header shows the number of files you've viewed. After reviewing as many files as you want, you can approve the pull request or request additional changes by submitting your review with a summary comment.
Tip
You can find a pull request where you or a team you're a member of is requested for review with the search qualifier review-requested:[USERNAME]
or team-review-requested:[TEAMNAME]
. For more information, see Searching issues and pull requests.
Starting a review
You can use GitHub Codespaces to test, run, and review pull requests.
-
Open the pull request in a codespace, as described in Using GitHub Codespaces for pull requests.
-
In the Activity Bar, click the GitHub Pull Request view. This view only appears when you open a pull request in a codespace.
-
To review a specific file, click the Open File icon in the Side Bar.
-
To add review comments, click the + icon next to the line number. Type your review comment and then click Start Review.
-
Optionally, you can suggest a change that the author of the pull request can click to commit if they agree with your suggestion. To do this, click and hold the + sign next to the first line you want to suggest changing, then drag the + sign to the last line you want to suggest changing. Then click Make a Suggestion in the comment box that's displayed.
The lines you selected are copied into the comment box, where you can edit them to suggest a change. You can add a comment above the line containing
```suggestion
to explain your suggested change.Click Add Comment to add your suggestion to the pull request.
-
When you are finished adding review comments, from the Side Bar you can choose to either submit the comments, approve the changes, or request changes.
For more information on reviewing pull requests in GitHub Codespaces, see Using GitHub Codespaces for pull requests.
Reviewing dependency changes
If the pull request contains changes to dependencies you can use the dependency review for a manifest or lock file to see what has changed and check whether the changes introduce security vulnerabilities. For more information, see Reviewing dependency changes in a pull request.
-
On the pull request, click Files changed.
-
On the right of the header for a manifest or lock file, display the dependency review by clicking the rich diff button.
-
You may also want to review the source diff, because there could be changes to the manifest or lock file that don't change dependencies, or there could be dependencies that GitHub can't parse and which, as a result, don't appear in the dependency review.
To return to the source diff view, click the button.
Marking a file as viewed
After you finish reviewing a file, you can mark the file as viewed, and the file will collapse. If the file changes after you view the file, it will be unmarked as viewed.
-
On the pull request, click Files changed.
-
On the right of the header of the file you've finished reviewing, select Viewed.
Submitting your review
After you've finished reviewing all the files you want in the pull request, submit your review.
-
On the pull request, click Files changed.
-
Above the changed code, click Review changes.
-
Type a comment summarizing your feedback on the proposed changes.
-
Select the type of review you'd like to leave:
- Select Comment to leave general feedback without explicitly approving the changes or requesting additional changes.
- Select Approve to submit your feedback and approve merging the changes proposed in the pull request.
- Select Request changes to submit feedback that must be addressed before the pull request can be merged.
-
Click Submit review.
Tip
- The Request changes option is purely informational and will not prevent merging unless a ruleset or classic branch protection rule is configured with the "require a pull request" option. If configured and a collaborator with
admin
,owner
, orwrite
access to the repository submits a review requesting changes, the pull request cannot be merged until the same collaborator submits another review approving the changes in the pull request. - Repository owners and administrators can merge a pull request even if it hasn't received an approving review, or if a reviewer who requested changes has left the organization or is unavailable.
- If both required reviews and stale review dismissal are enabled and a code-modifying commit is pushed to the branch of an approved pull request, the approval is dismissed. The pull request must be reviewed and approved again before it can be merged.
- When several open pull requests each have a head branch pointing to the same commit, you won’t be able to merge them if one or both have a pending or rejected review.
- If your repository requires approving reviews from people with write or admin permissions, then any approvals from people with these permissions are denoted with a green check mark, and approvals from people without these permissions have a gray check mark. Approvals with a gray check mark do not affect whether the pull request can be merged.
- Pull request authors cannot approve their own pull requests.