Reviewing changes in pull requests

Reviews allow collaborators to comment on the changes proposed in pull requests, approve the changes, or request further changes before the pull request is merged. Repository administrators can require that all pull requests are approved before being merged.

In a pull request, you can review and discuss commits, changed files, and the differences (or "diff") between the files in the base and compare branches.

To help you quickly review changes in a large pull request, you can filter changed files or use the file tree to navigate between files.

You can quickly find proposed changes to a method or function in a pull request in .go, .js, .ts, .py, .php, and .rb files.

After you open a pull request in a repository, collaborators or team members can comment on the comparison of files between the two specified branches, or leave general comments on the project as a whole.

You can view all of the comments made in a single pull request review.

If a pull request contains changes to dependencies, you can view a summary of what has changed and whether there are known vulnerabilities in any of the dependencies.

When reviewers suggest changes in a pull request, you can automatically incorporate the changes into the pull request or open an issue to track out-of-scope suggestions.

If your repository requires reviews, pull requests must have a specific number of approving reviews from people with write or admin permissions in the repository before they can be merged.

If your repository requires reviews, you can dismiss pull request reviews that are no longer valid or are unable to be approved by the reviewer.

When someone sends you a pull request from a fork or branch of your repository, you can merge it locally to resolve a merge conflict or to test and verify the changes before merging on GitHub Enterprise Server.