How to add reviewer github

Requesting a pull request review

After you create a pull request, you can ask a specific person to review the changes you’ve proposed. If you’re an organization member, you can also request a specific team to review your changes.

The ability to add multiple pull request reviewers or requests reviews from teams is available in public repositories with GitHub Free for organizations and legacy per-repository billing plans, and in public and private repositories with GitHub Team, GitHub Enterprise Server, and GitHub Enterprise Cloud. For more information, see «GitHub’s products.»

Repositories belong to a personal account (a single individual owner) or an organization account (a shared account with numerous collaborators or maintainers). For more information, see «Types of GitHub accounts.» Owners and collaborators on a repository owned by a personal account can assign pull request reviews. Organization members with triage permissions can also assign a reviewer for a pull request.

To assign a reviewer to a pull request, you will need write access to the repository. For more information about repository access, see «Repository roles for an organization.» If you have write access, you can assign anyone who has read access to the repository as a reviewer.

Organization members with write access can also assign a pull request review to any person or team with read access to a repository. The requested reviewer or team will receive a notification that you asked them to review the pull request. If you request a review from a team and code review assignment is enabled, specific members will be requested and the team will be removed as a reviewer. For more information, see «Managing code review settings for your team.»

Note: Pull request authors can’t request reviews unless they are either a repository owner or collaborator with write access to the repository.

You can request a review from either a suggested or specific person. Suggested reviewers are based on git blame data. If you request a review, other people with read access to the repository can still review your pull request. Once someone has reviewed your pull request and you’ve made the necessary changes, you can re-request review from the same reviewer. If the requested reviewer does not submit a review, and the pull request meets the repository’s mergeability requirements, you can still merge the pull request.

Under your repository name, click

Pull requests.

In the list of pull requests, click the pull request that you’d like to ask a specific person or a team to review.

Navigate to Reviewers in the right sidebar.

To request a review from a suggested person under Reviewers, next to their username, click Request.

Optionally, to request a review from someone other than a suggested person, click Reviewers, then click on a name in the dropdown menu.

Optionally, if you know the name of the person or team you’d like a review from, click Reviewers, then type the username of the person or the name of the team you’re asking to review your changes. Click their team name or username to request a review.

After your pull request is reviewed and you’ve made the necessary changes, you can ask a reviewer to re-review your pull request. Navigate to Reviewers in the right sidebar and click

next to the reviewer’s name whose review you’d like.

Reviewing proposed changes in a pull request

In this article

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.

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.

Starting a review

Under your repository name, click

Pull requests.

In the list of pull requests, click the pull request you’d like to review.

On the pull request, click

Files changed.

You can change the format of the diff view in this tab by clicking

and choosing the unified or split view. The choice you make will apply when you view the diff for other pull requests.

You can also choose to hide whitespace differences. The choice you make only applies to this pull request and will be remembered the next time you visit this page.

Optionally, filter the files to show only the files you want to review or use the file tree to navigate to a specific file. For more information, see «Filtering files in a pull request.»

In the comment field, type your comment.

Optionally, to suggest a specific change to the line or lines, click

, then edit the text within the suggestion block.

When you’re done, click Start a review. If you have already started a review, you can click Add review comment.

Before you submit your review, your line comments are pending and only visible to you. You can edit pending comments anytime before you submit your review. To cancel a pending review, including all of its pending comments, scroll down to the end of the timeline on the Conversation tab, then click Cancel review.

You can use GitHub Codespaces to test, run, and review pull requests.

For more information on reviewing pull requests in 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

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.

Type a comment summarizing your feedback on the proposed changes.

Select the type of review you’d like to leave:

Click Submit review.

Tips:

About pull request reviews

In this article

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.

About pull request reviews

After a pull request is opened, anyone with read access can review and comment on the changes it proposes. You can also suggest specific changes to lines of code, which the author can apply directly from the pull request. For more information, see «Reviewing proposed changes in a pull request.»

By default, in public repositories, any user can submit reviews that approve or request changes to a pull request. Organization owners and repository admins can limit who is able to give approving pull request reviews or request changes. For more information, see «Managing pull request reviews in your organization» and «Managing pull request reviews in your repository.»

Repository owners and collaborators can request a pull request review from a specific person. Organization members can also request a pull request review from a team with read access to the repository. For more information, see «Requesting a pull request review.» You can specify a subset of team members to be automatically assigned in the place of the whole team. For more information, see «Managing code review settings for your team.»

Reviews allow for discussion of proposed changes and help ensure that the changes meet the repository’s contributing guidelines and other quality standards. You can define which individuals or teams own certain types or areas of code in a CODEOWNERS file. When a pull request modifies code that has a defined owner, that individual or team will automatically be requested as a reviewer. For more information, see «About code owners.»

You can schedule reminders for pull requests that need to be reviewed. For more information, see «Managing scheduled reminders for pull requests.»

A review has three possible statuses:

Tips:

You can view all of the reviews a pull request has received in the Conversation timeline, and you can see reviews by repository owners and collaborators in the pull request’s merge box.

You can resolve a conversation in a pull request if you opened the pull request or if you have write access to the repository where the pull request was opened.

To indicate that a conversation on the Files changed tab is complete, click Resolve conversation.

The entire conversation will be collapsed and marked as resolved, making it easier to find conversations that still need to be addressed.

If the suggestion in a comment is out of your pull request’s scope, you can open a new issue that tracks the feedback and links back to the original comment. For more information, see «Opening an issue from a comment.»

Discovering and navigating conversations

You can discover and navigate to all the conversations in your pull request using the Conversations menu that’s shown at the top of the Files Changed tab.

From this view, you can see which conversations are unresolved, resolved, and outdated. This makes it easy to discover and resolve conversations.

Re-requesting a review

You can re-request a review, for example, after you’ve made substantial changes to your pull request. To request a fresh review from a reviewer, in the sidebar of the Conversation tab, click the

Repository administrators can require that all pull requests receive a specific number of approving reviews before someone merges the pull request into a protected branch. You can require approving reviews from people with write permissions in the repository or from a designated code owner. For more information, see «About protected branches.»

Tip: If necessary, people with admin or write access to a repository can dismiss a pull request review. For more information, see «Dismissing a pull request review.»

Managing code review settings for your team

In this article

You can decrease noise for your team by limiting notifications when your team is requested to review a pull request.

Team maintainers and organization owners can configure code review settings.

Code review settings are available in all public repositories owned by an organization, and all private repositories owned by organizations on GitHub Team, GitHub Enterprise Server 2.20+, and GitHub Enterprise Cloud. For more information, see «GitHub’s products.»

About code review settings

To reduce noise for your team and clarify individual responsibility for pull request reviews, you can configure code review settings.

About team notifications

When you choose to only notify requested team members, you disable sending notifications to the entire team when the team is requested to review a pull request if a specific member of that team is also requested for review. This is especially useful when a repository is configured with teams as code owners, but contributors to the repository often know a specific individual that would be the correct reviewer for their pull request. For more information, see «About code owners.»

About auto assignment

When you enable auto assignment, any time your team has been requested to review a pull request, the team is removed as a reviewer and a specified subset of team members are assigned in the team’s place. Code review assignments allow you to decide whether the whole team or just a subset of team members are notified when a team is requested for review.

When code owners are automatically requested for review, the team is still removed and replaced with individuals unless a branch protection rule is configured to require review from code owners. If such a branch protection rule is in place, the team request cannot be removed and so the individual request will appear in addition.

Code review assignments automatically choose and assign reviewers based on one of two possible algorithms.

The round robin algorithm chooses reviewers based on who’s received the least recent review request, focusing on alternating between all members of the team regardless of the number of outstanding reviews they currently have.

The load balance algorithm chooses reviewers based on each member’s total number of recent review requests and considers the number of outstanding reviews for each member. The load balance algorithm tries to ensure that each team member reviews an equal number of pull requests in any 30 day period.

Any team members that have set their status to «Busy» will not be selected for review. If all team members are busy, the pull request will remain assigned to the team itself. For more information about user statuses, see «Setting a status.»

Configuring team notifications

In the top right corner of GitHub.com, click your profile photo, then click Your organizations.

Click the name of your organization.

Under your organization name, click

Teams.

On the Teams tab, click the name of the team.

At the top of the team page, click

In the left sidebar, click

Select Only notify requested team members.

Click Save changes.

Configuring auto assignment

In the top right corner of GitHub.com, click your profile photo, then click Your organizations.

Click the name of your organization.

Under your organization name, click

Teams.

On the Teams tab, click the name of the team.

At the top of the team page, click

In the left sidebar, click

Select Enable auto assignment.

Under «How many team members should be assigned to review?», use the drop-down menu and choose a number of reviewers to be assigned to each pull request.

Under «Routing algorithm», use the drop-down menu and choose which algorithm you’d like to use. For more information, see «Routing algorithms.»

Optionally, to always skip certain members of the team, select Never assign certain team members. Then, select one or more team members you’d like to always skip.

Optionally, to include members of child teams as potential reviewers when assigning requests, select Child team members.

Optionally, to count any members whose review has already been requested against the total number of members to assign, select Count existing requests.

Optionally, to remove the review request from the team when assigning team members, select Team review request.

Click Save changes.

Disabling auto assignment

In the top right corner of GitHub.com, click your profile photo, then click Your organizations.

Click the name of your organization.

Under your organization name, click

Teams.

On the Teams tab, click the name of the team.

At the top of the team page, click

Select Enable auto assignment to remove the checkmark.

Click Save changes.

Help us make these docs great!

All GitHub docs are open source. See something that’s wrong or unclear? Submit a pull request.

Adding default reviewers to Github repository

2 Answers 2

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

You need to be sure that your base branch has:

You will need also to be sure that:

The pattern is followed by one or more GitHub usernames or team names using the standard @username or @org/team-name format.

(I don’t see @ in your case)

You can also refer to a user by an email address that has been added to their GitHub account, for instance user@example.com.

If the syntax is correct, then you can contact GitHub support to have them investigate.

The OP Pratheep actually find this is working:

You need the @ and referring to my last screenshot above, you don’t see the reviewers in the list when creating the PR.
But once the PR is created, then you will see the reviewers in the list.

I believe it was by design not to show. Because if you show the reviewers in that list before the PR is created, the names can be removed.
This way no one can create a PR without notifying the codeowners/default reviewers.