We're moving from Bitbucket to GitHub and one thing we are struggling with are peer code reviews that worked very smoothly on Bitbucket like this:

  1. Author opened a Pull Request (GitHub: the same)
  2. Author added his/her colleagues as reviewers (GitHub: ?? struggling here with multiple assignees)
  3. Reviewer either:
    1. Approved the PR with green check mark (GitHub: ??)
    2. Added comments (GitHub: the same)
    3. Created lightweight tasks (GitHub: sort of similar if - [ ] syntax is used in the PR description; shame that it doesn't work for tasks )
  4. There's a list of PRs where I can see at a glance which are reviewed and OK to be merged and which need further attention (GitHub: ??)

I should point out that we want to avoid 3rd party code review tools if at all possible and would like to stay on vanilla GitHub with some sort of workarounds.

  • 1
    Sounds like you might be switching prematurely. Why switch anyway, especially if the new thing doesn't have all the features that you need?
    – nanny
    Commented Nov 2, 2015 at 14:37
  • Write a comment to your prq, and highlight @whoever you want to get a notification. Reviewer can add tags to show their review opinion.
    – Wilbert
    Commented Nov 2, 2015 at 16:18
  • Also note that you can @mention a whole team e.g. @MyCompany/developers
    – Whymarrh
    Commented Nov 6, 2015 at 19:47

1 Answer 1


From what I've seen, most of those steps are done on Github by convention, and not by any official Github-provided process.

My employer uses Github, I run a good number of small open source projects, and make occasional contributions to other open source projects.

Here is how I've usually seen it done:

Author adding his/her colleagues as reviewers:

This varies from project to project, but in general, the assigned peer reviewers are all of the contributors to the project.

Open source projects seem to have a rough hierarchy - maybe their convention would be to only merge after a "core" contributor has given the okay.

At the shop where I am currently employed, we merge after any one of the half-dozen developers on the team has given their approval.

On rare occasions someone on the team may use a comment to specifically call out another developer that they think should peer review the code before it is merged, but otherwise, whoever gets there first and feels like doing so can review and make comments.

Reviewer approval:

Approval is typically shown by making a comment on the pull request saying "+1" or "lgtm" (looks good to me).

Lightweight tasks:

I've used the checkboxes as well, but in most cases, every comment on a pull request is considered an implicit "task" that is resolved either by:

  • changing the code that the line is commenting on
  • responding with another comment

Seeing at a glance what is approved and what still needs reviewed:

I have used the Looks Good To Me extension for Chrome, which gives you such a view from the Pull Requests screen. The pull requests list view seems to have been broken by recent Github changes, though.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.