A thorough code review on GitHub takes five steps: read the PR description, survey the diff, read the code line by line against a mental checklist, leave clear inline comments, and submit with the right status. Done carefully, a PR under 200 lines takes 20 to 30 minutes. One over 400 lines needs at least 45.

Most developers know the steps in theory. The gap shows up in practice: reviewers open Files Changed before they've read the ticket, miss the security issue on line 47, and leave comments the author can't act on. This guide walks each step in order so you can run a review that catches what matters.

What you need before you start

You need a GitHub account with read access to the repository. If you plan to run the code locally, you'll need a clone of the repo and whatever runtime the project uses. Before you touch anything, read the PR description and the linked ticket so you know what "correct" looks like for this specific change.

Check the diff size on the Files Changed tab. GitHub shows the number of changed lines near the top. A PR over 400 lines is hard to review well in one sitting. If you're the author, that's a signal to split future PRs. If you're the reviewer, block out at least 30 uninterrupted minutes and resist the urge to rush.

1. Read the PR description and linked ticket

Before opening a single file, read the PR description, any linked issue, and the acceptance criteria. You can't judge whether code is correct until you know what it's supposed to do.

On GitHub, the description sits at the top of the Conversation tab. Linked issues appear there too, usually written as "Closes #123" or "Fixes #456". Click through to the issue and read it. Acceptance criteria often live there rather than in the PR itself.

If the description is missing or vague, post a comment and ask before reviewing. A review without context produces noise, not signal. You've done this step correctly when you can state in one sentence what the PR is trying to do, and what it is explicitly not trying to do.

2. Survey the diff before commenting

2a. Get a structural picture of the changes first

Open the Files Changed tab and use the file tree on the left to scan which files moved, which are new, and which are deleted. This gives you the shape of the change before you read a single line. A PR that touches a model, its serialiser, and a migration is a different kind of review than one that only touches a single utility function.

2b. Set your diff preferences

GitHub's default view is a split diff. Switch to unified if you find it easier to follow logic across large functions. The toggle sits in the top-right of the Files Changed tab. Use the gear icon to hide whitespace-only changes so they don't obscure real edits. Once your preferences are set, they persist across reviews on that repository.

3. Review the code line by line with a checklist in mind

3a. Check correctness and logic first

Read each changed function and ask whether it does what the ticket says. Look for off-by-one errors, unhandled edge cases, and incorrect conditionals. These are the bugs that reach production. Correctness issues also tend to be the ones an author is least likely to catch themselves, because they wrote the code with a specific happy path in mind.

3b. Check security and data handling

Flag any user input that flows into a query, a file path, or a shell command without sanitisation. Check that secrets aren't hardcoded, and that new API endpoints have the right authentication guards. Security issues are the most commonly skipped category in fast reviews, partly because they require you to trace data flow rather than just read the changed lines in isolation. Understanding what separates a senior review from a junior one often comes down to exactly this: tracing inputs rather than skimming output.

3c. Check style and maintainability last

Naming, formatting, and test coverage matter, but they're less urgent than correctness. Do a separate pass for style so those comments don't crowd out the substantive findings. If your team uses a linter, point authors to the linter rule rather than explaining the style preference yourself.

4. Leave comments that are clear and actionable

A useful review comment names the problem, explains why it matters, and suggests or asks about a fix. A comment that only says "this looks wrong" forces the author to guess. Writing comments that are actionable rather than just correct is a distinct skill from spotting the problem in the first place.

On GitHub, click the blue plus icon on a line to open an inline comment. To comment on a range, click the first line number, hold Shift, and click the last. Always use "Start a review" rather than "Add single comment" so all your comments publish together instead of firing as a stream of individual notifications.

Label your comments. "nit:" signals a minor style point that the author can address or ignore. A comment with no label should be treated as blocking by default. GitHub's suggestion blocks let you propose an exact fix the author can commit with one click; use them for small, unambiguous corrections. You've done this step correctly when every comment has a clear action the author can take.

5. Submit your review and follow through

5a. Choose the right review status

GitHub gives you three options on submit: Comment, Approve, or Request Changes. Use Comment for observations that don't carry a verdict. Use Request Changes when at least one issue must be fixed before merge. Use Approve only when you're satisfied the code is ready as written. Approving with open blocking questions muddles the merge record and shifts responsibility to the author unfairly.

5b. Re-review after changes are pushed

When the author pushes a fix, GitHub marks each resolved thread. Re-read the changed sections, and the logic immediately surrounding them if the fix was non-trivial. Dismiss your Request Changes status once the blockers are resolved. Leaving it open after resolution stalls the merge and creates unnecessary friction for the author.

5c. Build the habit of tracking what you miss

Most reviewers never find out what they skipped. If a bug reaches production, it rarely gets traced back to a specific reviewer missing a specific line. Practising on graded PRs in a tool like Goodcatch shows you exactly which bug classes you overlook most often, so your real reviews improve over time. Habits that keep developers stuck at junior often include never measuring what they miss.

Frequently asked questions

How many files is too many to review in one GitHub PR?

There's no hard file limit, but changed line count is a better signal than file count. Reviews of more than 400 changed lines are where thoroughness tends to drop. If you're the reviewer, split the session across two sittings rather than rushing the second half.

Should you run the code locally before approving on GitHub?

For simple refactors or documentation changes, probably not. For any PR that touches data mutations, authentication, or external integrations, running the code locally and testing the edge cases yourself is worth the time. The diff alone won't show you runtime behaviour.

What should you do if you don't have enough context to review a section of the PR?

Say so directly in a comment. "I'm not familiar enough with the payment module to verify this logic, flagging for someone who owns that area" is a useful review contribution. Approving code you can't evaluate gives false confidence. If the PR touches parts of the system you own differently than parts you don't, there's a specific approach for splitting that attention.

Start practising on real pull requests with instant feedback on what you caught and what you missed.