A reviewer is someone you've asked to read the code and leave a verdict. An assignee is whoever owns getting the pull request over the line. GitHub keeps them as two separate fields, and only one of them can unblock a merge.
TL;DR
- Reviewers get a review request, show up in
review-requested:@me, get a status in the sidebar, and their approval can satisfy branch protection. - Assignees are a marker of ownership. They get a notification and a search qualifier, and that's all. GitHub never blocks or unblocks anything because of them.
- Assign the author, or whoever will actually merge. Request reviews from the people who should read the diff.
- Putting someone in both fields doesn't make the review more urgent. It's just noise.
What does a reviewer actually do on GitHub?
Requesting a review sets off a few concrete things:
- The person gets a notification with the reason
review_requested. - The PR shows up for them in the
review-requested:@mesearch, and in every tool built on that search. - Their name goes into the Reviewers box in the sidebar with a status icon: pending, commented, approved or changes requested.
- Once they submit a review, the request is cleared. The PR drops out of their pending queue until you click the re-request button (the little circular arrows next to their name).
That last point catches people out. Leave a review with a couple of comments, then get pinged two days later with "did you see my fixes?" That's usually because nobody re-requested, so the PR was quietly sitting outside your queue the whole time.
You can request reviews from individuals, and in an organization you can request one from a team. GitHub's page on requesting a pull request review covers who can request from whom. The status icons have quirks of their own, and I went through them in what each GitHub reviewer status means.
What does an assignee do?
Mostly it just sits there, and that's fine.
Assignees on a pull request use the same field issues do. You can assign up to 10 people, including yourself, according to GitHub's docs on assigning issues and pull requests. Assigning someone sends them a notification (reason assign) and makes the PR findable with assignee:@me.
And that's where it ends. There's no status, no re-request, no merge gate. GitHub doesn't care whether an assignee has looked at the PR, approved it, or even remembers it exists.
That isn't a design flaw. Assignee answers a different question: whose job is it to get this thing merged? On an issue that's obviously useful. On a pull request the answer is usually the author, which is why so many teams ignore the field entirely.
The difference that actually matters is merging
If your repo has branch protection or a ruleset with "Require a pull request before merging" and a required number of approvals, those approvals come from reviews. Being assigned contributes nothing. An assignee who never submits a review counts for zero.
The flip side is less obvious. The approvals that count come from people with write access, whether or not anyone requested them. So a request is mostly about getting someone's attention. It isn't a permission slip. If a teammate wanders in and approves without being asked, that still counts.
The exception is code owners. With "Require review from Code Owners" turned on, an approval from a random teammate isn't enough. You need one from someone listed in CODEOWNERS for the files you touched. That's the one place where who reviews is enforced, not just how many. There's more on how those rules stack up in GitHub pull request review required.
Reviewer vs assignee, side by side
| Reviewer | Assignee | |
|---|---|---|
| What it means | Read the diff and leave a verdict | Owns the PR until it's done |
| Notification reason | review_requested | assign |
| Search qualifier | review-requested:@me, user-review-requested:@me | assignee:@me |
| Status in the sidebar | Pending, commented, approved, changes requested | None |
| Cleared automatically | Yes, when they submit a review | No, stays until removed |
| Counts toward required approvals | Yes, once they approve (with write access) | No |
| Can be a team | Yes, in organizations | No, people only |
| Filled in automatically by | CODEOWNERS, team review assignment | Nothing built in for PRs, so teams use a bot or an Action |
One naming trap. The team setting that picks reviewers for you, round robin or load balanced, is called code review assignment. It assigns reviewers, not assignees. Whoever named that has caused a lot of Slack threads.
So who should be the assignee?
My opinion: the author, by default, every time. A few reasons:
- It makes
assignee:@memean something: the PRs I'm responsible for landing. That's different fromauthor:@me, because ownership can change hands. - When ownership does change (the author goes on holiday, someone picks up a stale branch), you reassign, and the search follows the change.
- It keeps the reviewer field clean. Reviewers are on the hook for a review, not for the whole PR.
The exceptions are real but narrow. Maybe a release manager owns a batch of PRs, or an external contributor's PR needs a maintainer to shepherd it through. In both cases the assignee is the person who'll merge it, which is still the same idea.
Patterns that cause trouble
- Assigning the reviewer instead of requesting a review. This is the classic one. They get an
assignnotification, nothing shows up in theirreview-requested:@mequeue, and the sidebar shows no pending review. If they work from their review queue (most people do), the PR doesn't exist for them. - Assigning and requesting the same person. Harmless, but it doubles the notifications and tells them nothing new. If you need it to feel urgent, leave a comment.
- Assigning the tech lead to everything. Now
assignee:@mereturns 60 PRs for one person and zero for everyone else, so nobody uses it.
Setting both from the command line
If you open PRs with the GitHub CLI, you can set both fields in one go:
# open a PR, request two reviewers, assign yourself
gh pr create --reviewer alice,bob --assignee @me
# add a team as reviewer and take ownership of an existing PR
gh pr edit 482 --add-reviewer my-org/backend --add-assignee @me
# take a reviewer off
gh pr edit 482 --remove-reviewer bob
To actually find things, these searches are worth bookmarking. The qualifiers are all in GitHub's docs on searching issues and pull requests:
is:open is:pr review-requested:@me
is:open is:pr user-review-requested:@me
is:open is:pr assignee:@me
is:open is:pr author:@me review:changes_requested
is:open is:pr reviewed-by:@me -author:@me
The difference between the first two matters on bigger teams. review-requested:@me includes requests made to any team you're on. user-review-requested:@me only shows the ones addressed to you by name. If team requests are flooding your queue, the second one is the list you actually need to clear.
The same searches work from the terminal:
gh pr list --search "review-requested:@me"
gh search prs --assignee @me --state open
If you want the bigger picture of how requests, reviews and merges fit into a team's routine, the PR review workflow guide covers that end to end.
Where PRFlow fits, and where it doesn't
In practice the pain is almost always on the reviewer side. Review requests arrive from five repos, the emails pile up (I've complained about GitHub notification emails before), and somewhere in there is a PR you said you'd look at on Tuesday.
PRFlow is a Chrome side panel that lists your open PRs across repos with their review status, labels, comment counts and diff size, so you don't need a tab per PR. Its filters line up with the reviewer side of this article: needs my review is review-requested:@me, plus created by me and reviewed but not merged.
What it doesn't do: it's built around review requests, not assignment. If your team really runs on assignee:@me, a bookmarked GitHub search is the better tool for that part. It also won't review anything for you. You still have to read the diff.
The reviewed-but-not-merged filter exists because of the quirk from the start of this article. Once you submit a review, the request is cleared and the PR leaves review-requested:@me. If the author pushes fixes and forgets to re-request, nothing on GitHub's side puts it back in front of you. That gap, between I reviewed it and it actually merged, is the one worth watching. Neither the reviewer field nor the assignee field covers it on its own.