GitHub code review: how to review pull requests and add AI

How code review works on GitHub

A review on GitHub is a set of comments on a pull request, submitted together with one of three outcomes:

• Comment: general feedback, with no decision either way.
• Approve: the changes are ready to merge.
• Request changes: feedback the author should address before merging.

Anyone with read access to the repository can review and comment. What a review means depends on the branch: on an unprotected branch, even Request changes is only a signal, and anyone with write access can still merge. Once a branch protection rule or ruleset requires reviews, approvals and code owner sign-off become merge conditions. Most teams want both halves: a habit of reading every change, and a rule that stops unreviewed code reaching main.

A good review starts before anyone opens the diff. A clear description, written with a pull request template, tells the reviewer what changed, why, and how it was tested.

How to review a pull request on GitHub, step by step

1. Request reviewers

On the pull request, find Reviewers in the right sidebar. Click Request next to a suggested reviewer (GitHub suggests people from git blame data on the changed lines), or click Reviewers and type a username or team name. Pressing Q on the pull request opens the same menu.

You need write access to the repository to request a review, and you can request anyone with read access. Requesting a large team can notify every member; a team’s code review settings can assign specific members automatically instead.

2. Open the Files changed tab

The Files changed tab shows the diff. Use the file tree or the Filter changed files field to jump to what matters most, and tick Viewed in a file’s header once you’ve read it. The file collapses, the progress bar counts it, and if the author changes that file later, GitHub unmarks it so you know to look again.

3. Comment on lines, ranges and files

Hover over a line and click the blue comment icon to comment on it. For a range, click the first line number, then Shift-click the last one (or drag), and click the comment icon on the last line. A comment icon in each file header takes a comment on the whole file. Keep each comment to one point and say how important it is; our guide to writing code review comments has examples.

4. Suggest the exact change

When the fix is small, click the suggestion icon in the comment box (or press Ctrl+G, ⌘+G on a Mac) and edit the code inside the suggestion block. The author can then apply it with Commit suggestion, or collect several with Add suggestion to batch and commit them together. Applying suggestions creates one commit on the pull request’s branch and credits each suggester as a co-author. It needs write access, and for a pull request from a fork, the author must allow edits by maintainers.

5. Start a review instead of posting single comments

The first time you comment, GitHub offers two buttons: Comment posts it right away, and Start a review holds it as pending, visible only to you. Later comments use Add review comment. Batching matters because everyone watching the pull request or repository is notified of each posted comment; a review sends one notification with all of them.

6. Submit: Comment, Approve or Request changes

Click Review changes above the diff, write a short summary, pick one of the three outcomes and click Submit review. To throw a pending review away, open the same menu and choose Discard review. Authors can’t approve their own pull requests.

7. Address feedback, resolve and re-request

The author pushes fixes or commits suggestions, then marks each handled thread with Resolve conversation; the pull request’s author and anyone with write access can resolve. The Conversations menu on Files changed lists unresolved, resolved and outdated threads. When the changes are ready, the author clicks the re-request icon next to the reviewer’s name under Reviewers to ask for another pass.

8. Merge when the rules pass

Merge once the branch’s requirements are met: the number of approvals, a code owner’s review, resolved conversations and passing status checks, whichever your branch protection rule or rulesets ask for. Those settings are covered below.

Request the right reviewers automatically with CODEOWNERS

A CODEOWNERS file maps paths to the people or teams who own them. Put it in .github/, the repository root or docs/; GitHub uses the first one it finds in that order. When someone opens a pull request that changes owned code, GitHub requests a review from the owners automatically.

# Default owners for everything
*               @acme/platform

# Later patterns win over earlier ones
/docs/          @acme/docs
/billing/       @acme/payments @lee
*.sql           @acme/data

The last matching pattern takes precedence, so put broad rules first and specific ones below. Owners need explicit write access to the repository, even when a team’s members already have it. Draft pull requests don’t request owners; they’re notified when the draft is marked ready for review.

How to require code review before merging

In the repository’s Settings, open Branches to add a classic branch protection rule, or create a ruleset for the branch instead. Under Require a pull request before merging, the options that shape review are:

• Require approvals, with the number of approving reviews needed. Only approvals from people with write permission or from a code owner count.
• Dismiss stale pull request approvals when new commits are pushed, so an approval always covers the current diff.
• Require review from Code Owners; one approval from any owner of a file satisfies it.
• Require approval of the most recent reviewable push, by someone other than the person who pushed it. This stops an author from pushing new code after a teammate approves.

Next to it, Require conversation resolution before merging holds the merge until every comment on the pull request is resolved.

Require status checks to pass before merging adds automated gates: CI, tests, or an AI review check. A required check must end Success, Neutral or Skipped. By default the branch must also be up to date with the base branch, which costs more rebuilds but avoids merging two changes that pass apart and fail together. You can pin a check to the app that should report it, so nothing else can satisfy it.

GitHub applies only one branch protection rule to a branch at a time, but several rulesets can target the same branch and their rules combine, with the strictest version of a rule winning. A ruleset requiring three approvals alongside a protection rule requiring two means three approvals are needed. Anyone with read access can view a repository’s active rulesets. (Source: GitHub Docs, About rulesets, as of November 2026.)

Keyboard shortcuts for GitHub PR review

• Q: request a reviewer.
• T on Files changed: jump to the Filter changed files field.
• C on Files changed: pick which commits the diff shows, useful for reviewing only what changed since your last pass.
• Click a line number, then Shift-click another: comment on the range.
• Ctrl+G (⌘+G): insert a suggestion.
• Ctrl+Shift+Enter (⌘+Shift+Enter): submit a review comment.
• Alt-click (Option-click): collapse or expand all outdated and resolved comments.

The tools only help if reviewers know what to look for. Keep a short code review checklist next to the diff, and see code review best practices for sizing pull requests and turnaround times.

Adding AI code review on GitHub

AI reviewers plug into the same flow: they appear as a reviewer, post review comments on the diff, and some report a status check you can require. There are four common ways to add one.

GitHub Copilot code review

With a paid Copilot plan, select Copilot under Reviewers like any teammate, or have it review every pull request through your personal settings or a ruleset. Copilot leaves an overview and inline comments. By default its reviews don’t count toward required approvals, and the agentic review runs on GitHub Actions, so it uses Actions minutes on GitHub-hosted runners. Copilot Free doesn’t include it. Setup, pricing and how it compares are in our GitHub Copilot code review guide.

A GitHub App: HeyDeer

A review app installs on your organization or account and reviews the repositories you select. HeyDeer reviews each pull request against the whole repository and verifies each finding before posting it. It posts one GitHub review per run, with inline comments on the changed lines, and reports the result in a check named HeyDeer Review on the commit it reviewed. Comment @heydeer review to request a review, or set it to review once per pull request or on every push.

The check is what turns an AI review into a merge rule. By default, findings don’t fail it. Turn on Fail the check when issues are found in HeyDeer, then add HeyDeer Review as a required status check with HeyDeer as its source, and a pull request can’t merge until its findings are fixed or declined. The HeyDeer Review check docs walk through it. Optional automatic approval lets HeyDeer approve routine pull requests once no findings remain, while high-risk ones wait for a person, and the Free plan includes 1,000 credits in the first month.

Codex and Claude Code

Coding agents can review too. Codex reviews a pull request when you comment @codex review, or automatically once you turn that on; see Codex code review. Claude Code reviews locally with a slash command and can post findings as inline comments, and Team and Enterprise admins can turn on reviews of every pull request; see the Claude Code review skill. When the same agent wrote the change, a reviewer built on a different model is more likely to catch what it missed.

Your own review bot with GitHub Actions

A workflow on the pull_request event (by default it runs when a pull request is opened, reopened or gets new commits) can send the diff to a model API and post the answer as review comments. Tools such as reviewdog turn linter output into review comments the same way. Plan for the limits: in pull requests from forks, secrets aren’t passed to the runner and GITHUB_TOKEN is read-only, so a bot can’t call a paid API or comment there without extra setup. You also own the prompt, the noise and the upkeep.

An AI reviewer only gates a merge on GitHub if it reports a status check that branch rules require, or if its approvals count toward required reviews. Comments alone are advice. Copilot’s reviews don’t count toward required approvals by default, while a review app that publishes a check, such as HeyDeer Review, can be made a required status check.

Which option fits

AI review works best as the first reader, not the last. Let it check the details on every push, then have a person look at design and product behavior once the check is green. To compare tools on precision, see the best AI code review tools.

Sources

1. GitHub Docs: Requesting a pull request review
2. GitHub Docs: Reviewing proposed changes in a pull request
3. GitHub Docs: Commenting on a pull request
4. GitHub Docs: Incorporating feedback in your pull request
5. GitHub Docs: About code owners
6. GitHub Docs: About protected branches
7. GitHub Docs: About rulesets
8. GitHub Docs: Keyboard shortcuts
9. GitHub Docs: About Copilot code review
10. GitHub Docs: Events that trigger workflows