Pull requests, or PRs, are a type of item on GitHub that represents a request from an engineer to merge some of their work into the main codebase. This work exists on a branch, which is separate from the main codebase.
Indicates that this PR is ready for review and the engineer wants it merged into the main codebase.
Indicates that this PR has been merged into the main codebase (considered “Done” in our process).
Indicates that this PR is in “Draft” state and is not ready for review or merging. Draft PRs are useful for team visibility, especially for parent branches that will be added to over time before being marked as “Ready.”
Indicates that a PR has been closed without merging. This can happen for various reasons, but we also consider this “Done” in our process.
When a PR is created, an engineer should request a review by assigning a “Reviewer.” There are four review states:
A small yellow dot next to a reviewer signals that the PR is awaiting their review. This PR will also appear in the review-requested filter on GitHub. (Example of review-requested query)
When a red icon appears next to a reviewer, it means the review has failed, and the requested changes are noted in the review comments. The engineer must then make these changes.
Once the updates are ready, the engineer clicks the “Re-request Review” icon to revert the PR to “Awaiting Review.”
In our process, a PR with requested changes moves to “In Progress” and returns to “CR” when a review is re-requested.
Click this button to re-request review!
A reviewer may leave a comment without explicitly approving or failing the PR. This can happen if there’s a question or a blocker preventing the review from being conducted.
When a review passes, a green tick appears next to the reviewer’s name, meaning the PR has passed inspection (e.g., CR or QA in our process).
Due to how GitHub works, an approval may be auto-invalidated if new code is pushed to the branch.