Skip to main content
In GitHub’s collaborative workflow, a code review is the formal mechanism for giving feedback on a pull request (PR). When you submit a review you must select a status that signals the next steps for the contributor and the repository: Comment, Approve, or Request changes. Choose the status that matches the severity of your feedback and the repository’s branch protection rules so the team knows whether the PR can be merged.
Best practices for constructive reviews:
  • Focus on scope and clarity: flag only issues that affect correctness, security, or maintainability.
  • Use Comment for stylistic or non-blocking suggestions to avoid unnecessary workflow friction.
  • When requesting changes, include clear reproduction steps and a prioritized list of fixes.
Below are the three review submission states you can use and when to use each.
  • Comment — Use this to provide general feedback, ask technical questions, or note observations without changing the formal status of the pull request. This is a non-binding option intended to facilitate discussion and clarification without blocking or approving the merge.
  • Approve — This is the formal sign-off. Choose Approve when the proposed changes meet project requirements and are verified for integration into the base branch. An approval is often required by branch protection rules before a pull request can be merged.
The image shows a code review interface for a pull request, with options to comment, approve, or request changes. There's also a description of what each submission state entails.
  • Request changes — Use this when you identify critical bugs, security vulnerabilities, or architectural issues that must be fixed before the pull request can be merged. This status formally blocks the pull request until the author addresses the requested changes and you re-review.
Requesting changes prevents the pull request from being merged until the issues are resolved and the reviewer either re-approves or the branch protection rules are satisfied.
Summary table — quick reference Guidance for reviewers
  • Match the review status to impact: non-blocking feedback = Comment, acceptance = Approve, blocking issues = Request changes.
  • Be specific in comments: link to failing tests, include code snippets, or point to relevant docs.
  • If a change is required but small, consider leaving a clear Comment and following up with a suggested patch; otherwise use Request changes.
Links and references

Watch Video