How to review a pull request on GitHub: a step-by-step guide

To review a pull request on GitHub, open the Files changed tab, comment on the lines that need it, then click Submit review and choose Comment, Approve or Request changes. If you're looking for the Review changes button from older guides, it's now Submit review: GitHub's improved Files changed page started rolling out as the default on January 22, 2026.

This guide covers how to review a pull request on GitHub click by click, with labels checked against GitHub's docs and changelog as of October 2026, and the gh command for most steps. If your screen still says Review changes, you're on the classic page: same flow, minus a few features below.

What is a pull request in GitHub?

A pull request (PR) is a proposal to merge a branch's code changes into a project, and it's where GitHub code review happens. Its page holds the description, discussion, CI checks and diff, so the author and reviewers can decide together when it's ready to merge.

How to review a pull request on GitHub: the short version

1. Open the pull request, read the description and any linked issue, and check CI.

2. Click the Files changed tab.

3. Hover over a line, click the blue +, write your comment, and click Start a review.

4. To propose exact code, click Insert a suggestion and edit the code in the block.

5. Tick Viewed on each file when you finish it.

6. Click Submit review, write a summary, choose Comment, Approve or Request changes, and click Submit review again.

7. Once the author asks for another look, review what changed since your last pass.

How to approve a pull request on GitHub

To approve a pull request in GitHub, open its Files changed tab, click Submit review, choose Approve and click Submit review again. From a terminal, run gh pr review 123 --approve. Your approval counts toward required approvals if you have write access, and you can't approve your own pull request.

Approve is one of three decisions:

If the repository dismisses stale approvals, any push that changes the diff removes yours, and you'll need to approve again.

GitHub pull request review, step by step

1. Read the description and check CI

Read the description and any linked issue first: they say what the code should do. Then ask whether the change should exist at all. Google's code review guide puts this first: if it shouldn't, say so right away and explain why, before anyone writes line comments on code the author will throw away.

Check CI next. The Checks tab shows what ran and why anything failed, and the Merge status button in the pull request header lists blockers and missing approvals. If tests fail, ask whether the PR is ready before you spend time on it.

2. Open the Files changed tab

Set the page up before you read:

• The gear menu switches between unified and split diffs and can hide whitespace changes, so a reindented file shows only the lines whose content changed.

• The Overview button in the toolbar keeps the description open next to the code.

• Press T to jump to the file filter, which filters both the file tree and the diff.

• Press C to review all commits, a range, or a single commit.

3. Comment on a line or a range

Hover over a line and click the blue + (labeled "Add a comment"). For a range, click the first line number, shift-click the last, then click the +. Expanding the diff lets you comment on unchanged lines too, which helps when the bug sits in a line the author didn't touch. For a whole file, click the comment icon on the right of the file header.

Then pick a button:

• Comment posts that one comment now.

• Start a review saves it as pending, visible only to you until you submit. Later comments use Add review comment.

Start a review for anything beyond a quick question. GitHub notifies everyone watching the pull request or repository of each standalone comment, while a review arrives as one batch.

4. Suggest the exact change

If you know the fix, write it out. Select the lines, start a comment, and click Insert a suggestion in the comment toolbar (Cmd+G on macOS, Ctrl+G on Windows and Linux). GitHub puts the selected lines in a suggestion block. Edit them into the fix, and say why above the block:

This throws when the list is empty. Return early:

```suggestion
if (items.length === 0) return [];
const first = items[0];
```

This throws when the list is empty. Return early:

```suggestion
if (items.length === 0) return [];
const first = items[0];
```

This throws when the list is empty. Return early:

```suggestion
if (items.length === 0) return [];
const first = items[0];
```

Commit suggestion applies it as its own commit. To apply several in one commit, use Add suggestion to batch, then Commit suggestions, and GitHub credits each suggester in that commit as a co-author.

Keep suggestions for small, exact edits. Put design concerns in normal comments, with your reasoning.

5. Mark each file as Viewed

Tick Viewed in a file's header when you're done with it. The file collapses and counts toward the progress bar in the pull request header. If the author changes that file later, GitHub clears the mark.

6. Submit your review

Click Submit review, check your pending comments in the panel, write a summary, pick a decision (see the table above), and click Submit review again, or press Cmd+Enter / Ctrl+Enter.

Use the summary to separate blockers from the rest. "Two blocking issues in the auth middleware, the rest are nits" tells the author where to start.

To throw away a pending review, click Submit review, then Discard review.

7. Re-review after the author pushes

Authors request reviews under Reviewers in the pull request sidebar, which takes write access to the repository. After working through your comments, they click the Re-request review icon next to your name, or run gh pr edit 123 --add-reviewer your-username.

You don't need to reread everything:

• Press C and select only the commits pushed since your review.

• Start with the files that lost their Viewed mark.

• Open the Comments panel from the toolbar and check that each of your threads got a fix or an answer. Resolve the settled ones.

How to review a pull request with the gh CLI

To review a pull request with the gh CLI, read it with gh pr view and gh pr diff, check CI with gh pr checks, run it after gh pr checkout, and submit with gh pr review plus --approve, --request-changes or --comment. Line comments need the browser, and gh pr view 123 --web takes you there.

Find what's waiting for you (in the browser, github.com/pulls/review-requested lists them too):

gh search prs --review-requested=@me --state=open

gh search prs --review-requested=@me --state=open

gh search prs --review-requested=@me --state=open

Read the pull request, its comments, CI status and diff:

gh pr view 123
gh pr view 123 --comments
gh pr checks 123
gh pr diff 123 --name-only
gh pr diff 123 --exclude 'generated/*'

gh pr view 123
gh pr view 123 --comments
gh pr checks 123
gh pr diff 123 --name-only
gh pr diff 123 --exclude 'generated/*'

gh pr view 123
gh pr view 123 --comments
gh pr checks 123
gh pr diff 123 --name-only
gh pr diff 123 --exclude 'generated/*'

To run it, check out the branch. We'd add --worktree (gh 2.98 and later), which puts the PR in its own folder and leaves your current branch alone:

gh pr checkout 123
gh pr checkout 123 --worktree ../pr-123

gh pr checkout 123
gh pr checkout 123 --worktree ../pr-123

gh pr checkout 123
gh pr checkout 123 --worktree ../pr-123

Then submit with gh pr review. -b sets the review body, and without a PR number, gh reviews the pull request for your current branch:

gh pr review 123 --approve
gh pr review 123 --request-changes -b "fetchUser retries forever on a 500. Add a retry limit."
gh pr review 123 --comment -b "One question on the cache key, otherwise looks good."

gh pr review 123 --approve
gh pr review 123 --request-changes -b "fetchUser retries forever on a 500. Add a retry limit."
gh pr review 123 --comment -b "One question on the cache key, otherwise looks good."

gh pr review 123 --approve
gh pr review 123 --request-changes -b "fetchUser retries forever on a 500. Add a retry limit."
gh pr review 123 --comment -b "One question on the cache key, otherwise looks good."

What to look for in a pull request review

Spend your attention where a mistake costs the most. Check that the change does what its description says before you judge how it's written, and leave style for last, limited to what your linter misses. Work through each PR review in this order:

1. Intent. Does the change do what the description and issue say, and nothing else?

2. Correctness. Logic, edge cases such as empty input and nulls, error handling, concurrency.

3. Security and data. Auth checks, user input, secrets, migrations. If a manifest or lock file changed, the rich diff button on that file shows GitHub's dependency review (on public repositories, and private ones with GitHub Code Security).

4. Tests. Would they fail if the code were wrong? A test that can't fail proves nothing.

5. Design and readability. Does it fit the codebase, and will the next person understand it?

6. Style. Last, and only what your linter doesn't already catch. Automated code review covers what to hand to tools.

Our code review checklist covers each item in detail. If the change affects what users see, or you can't verify it by reading, check out the branch and run it.

Pull request review best practices

Most of these pull request best practices come from Google's public code review guide, which is worth reading in full:

• Respond within a business day. Google treats one business day as the longest a review request should wait for a first response.

• Comment on the code, not the person, and explain why. "This re-fetches the user for every row, so the page runs one query per row" gives the author something to act on. "Why did you do it this way?" doesn't.

• Label what matters. Prefix minor points with Nit:, ideas with Optional:, and background with FYI:. Without labels, authors may read every comment as mandatory.

• Ask when you don't understand. If the answer belongs in the code, ask for a clearer name or a code comment, since an explanation left in the review thread won't help the next reader.

• Approve code that's better, even if it isn't perfect. Google calls this its senior principle: approve once the change improves the overall health of the code. Save Request changes for real blockers and approve with nits otherwise.

• Point out what's good. A comment on a clean refactor or a sharp test teaches as much as a correction.

How to review a large pull request

Ask for a series of smaller PRs first: it's cheaper before you've read most of the diff. Google's guide treats about 100 lines as a reasonable change and 1,000 lines as usually too large, while leaving the call to the reviewer (Small CLs). If the PR has to stay big:

1. Review the core first. Read the file or two with the main logic before anything else, and if the design is wrong, send that comment now.

2. Cut the noise. Hide whitespace, filter out lock files and generated code, and go commit by commit if the author built the PR in clean steps. Teams can mark generated files with linguist-generated in .gitattributes, and GitHub then hides them in diffs by default.

3. Read the tests early. They show what the author expects the code to do.

4. Search outside the page. On the largest PRs, GitHub doesn't render the whole diff at once, so your browser's find can miss text. gh pr diff 123 or a local checkout lets you search everything.

Where AI review fits

We're biased here: this blog belongs to cubic (cubic.dev), an AI code review tool for GitHub. Weigh this section accordingly.

AI reviewers post findings as review comments. A good one takes the first pass on mechanical problems, like a missing null check or a query inside a loop, which leaves you free to judge intent and design.

GitHub's own option is GitHub Copilot code review, which you request from the same Reviewers menu as a teammate. By default it leaves a Comment review, which doesn't count toward required approvals.

Treat AI comments like any reviewer's: fix, reply or dismiss with a reason. And keep a human approval on the pull request. AI pull request review on GitHub walks through setting one up, and our AI code review page compares the main tools.

The review that helps most is the one the author can act on today.

If you want that first pass on your pull requests, try cubic. It's free for public repositories, and paid plans start with a 7-day trial.