GitHub Code Review

Review pull requests on GitHub: comment on lines, suggest changes, approve or request changes, and give feedback that helps.

Lesson 9 of 30Intermediate17 min read

A pull request isn't finished when it's opened: it's finished when someone else has read it. Code review is the step where a teammate looks at your changes before they reach main, catching bugs, asking questions and sharing better ways of doing things.

Good reviews make software more reliable and help everyone learn. Reviewers see how the rest of the team solves problems, and authors get feedback while the code is still fresh in their minds. Many teams won't merge anything without at least one approval.

In the pull requests lesson you opened a PR. In this lesson you'll sit on the other side of the table: reading a pull request's changes, leaving line comments and suggestions, submitting a review, testing a branch on your own computer and writing feedback that's clear and kind.

Reading the changes

Open the pull request and click Files changed. Each file shows removed lines in red and added lines in green.

  • Read the description first so you know what the change is meant to do.
  • Tick Viewed on each file as you finish it; GitHub hides it and remembers your place.
  • Use the file tree on the left to jump between files, and the settings gear to hide whitespace changes.
  • For big PRs, look at tests first: they show what the author expects the code to do.

Comments and suggestions

Hover over a line and click the blue + to comment on it. Drag down the + to comment on several lines at once.

Click the suggestion button (the small file icon with plus and minus) to propose an exact replacement:

Markdown
```suggestion
const total = price * quantity;
```

The author can apply a suggestion with one click, and it becomes a commit on their branch. Suggestions are ideal for typos and small fixes, because they save a round of back and forth.

Submitting a review

Instead of posting comments one by one, click Start a review on the first comment. Your comments stay pending until you click Finish your review and choose:

ChoiceMeaning
CommentGeneral feedback, no verdict
ApproveHappy for this to be merged
Request changesMust be addressed before merging

When the author has pushed fixes, they click the re-request review arrow next to your name, and you look again at just the new commits.

Reviewing locally and assigning reviewers

Sometimes you need to run the code. Fetch the PR's branch and try it:

Terminal
gh pr checkout 42

Without GitHub CLI, use git fetch origin then git switch branch-name. Reviewers are added in the PR's sidebar. A CODEOWNERS file in the repository can request reviews automatically, for example making the design team review every change in css/.

GitHub Code Review Syntax

Review commands

gh pr list                       # open pull requests
gh pr checkout 42                # get PR 42's branch locally
gh pr diff 42                    # see its changes in the terminal
gh pr review 42 --approve
gh pr review 42 --request-changes -b "Please add a test"
gh pr review 42 --comment -b "Looks good so far"

GitHub Code Review Summary

  • Review in the Files changed tab: read the description first, then each file.
  • Click + on a line to comment; drag to cover several lines.
  • Suggestions propose exact code the author can apply with one click.
  • Start a review to batch comments, then Comment, Approve or Request changes.
  • Use gh pr checkout <number> to run a PR locally; CODEOWNERS assigns reviewers automatically.

GitHub Code Review Examples

Each example shows the code, the output it produces and what each part does.

Example 1

A CODEOWNERS file

Text
# .github/CODEOWNERS
*               @samlee
/css/           @priya
/docs/          @ben @priya
*.js            @frontend-team
Output
Change to css/home.css   -> review requested from @priya
Change to docs/setup.md  -> review requested from @ben and @priya
Change to app.js         -> review requested from @frontend-team
Change to README.md      -> review requested from @samlee
Line-by-line explanation
  1. Line 1The file lives in .github, the repository root or docs.
  2. Line 2The * pattern matches everything and sets a default owner.
  3. Lines 3 to 5Later lines win, so more specific patterns go lower down.
Example 2

Reviewing a PR from the terminal

Terminal
gh pr checkout 42
npm test
gh pr review 42 --approve -b "Tested locally, works well."
Output
Switched to branch 'add-search'
  ✓ 18 tests passed
✓ Approved pull request #42
Line-by-line explanation
  1. Line 1Downloads the branch for PR 42 and switches to it.
  2. Line 2Run the project's tests or open the site to check the change yourself.
  3. Line 3Submit an approving review with a short message.
Example 3

Useful review comments

Text
✗ "This is wrong."
✓ "If the basket is empty, total is undefined here, so the page shows NaN.
   Could we return 0 when items.length is 0?"

✗ "Use a better name."
✓ "nit: `d` could be `discount`, so it's clear what it holds. Optional."

✓ "Nice idea moving this into a helper, it's much easier to follow."
Output
Good comments say what the problem is, why it matters
and what could be done, and they separate must-fix
issues from optional preferences.
Line-by-line explanation
  1. Lines 2 to 3Points to the exact situation, explains the effect and suggests a fix.
  2. Line 6"nit" marks a small, optional point.
  3. Line 8Positive feedback is part of a good review too.

Common GitHub Code Review Mistakes

Approving without reading

Don't
"LGTM" on a 900-line PR, two minutes after it was opened
Do
Read the description, check each file, run it if needed, then approve

LGTM means "looks good to me". It's only useful if you actually looked.

Huge pull requests

Don't
One PR: new design + database change + bug fixes (2,400 lines)
Do
Three PRs: database change, then design, then bug fixes

Smaller PRs get faster, more careful reviews.

Leaving comments unanswered

Don't
Push new commits and silently re-request review
Do
Reply "Done in 3e4f5a6" or explain why not, then resolve the thread

GitHub Code Review in Real Projects

Review culture

At most companies every change to production code is reviewed, and branch protection rules enforce it. Large open-source projects have maintainers who review contributions from strangers around the world. Studies of software teams consistently find that code review catches bugs early and spreads knowledge, so no single person is the only one who understands a part of the code.

GitHub Code Review FAQ

Can I approve my own pull request?

No. GitHub doesn't let the author of a pull request approve it, though you can leave comments on your own changes. If a repository requires approvals before merging, someone else has to give them.

What does Resolve conversation do?

It collapses a review comment thread to show that it's been dealt with. The conversation stays available if you expand it. A useful habit is to let the person who raised the point resolve it, or to explain your change in a reply before resolving.

How do I ask for a second review after making changes?

Push your changes, reply to the comments, then use the re-request review button next to the reviewer's name in the sidebar. They get a fresh notification. That's clearer than a comment saying "done", which can be missed.

How do I comment on several lines at once?

In the Files changed view, click the line number where the section starts and drag to the last line, or click the first line number and shift-click the last. The comment box then covers that whole range, and a suggestion in it replaces all of those lines.

Should I approve a pull request that only has small issues?

Often, yes. If the remaining points are minor, such as a typo or a naming suggestion, approve and leave the comments so the author can fix them before merging. Save Request changes for problems that really must be fixed first, such as bugs or security issues.

GitHub Code Review Exercises

Answer each one and check it instantly. If you get stuck, open the hint before the answer.

Fill in the blankseasy

Complete the command that downloads pull request 15 to review it locally.

gh pr  15
Multiple choiceeasy

Which tab shows a pull request's line-by-line changes?

Multiple choicemedium

What does a suggestion comment let the author do?

Multiple choicemedium

Which review result blocks merging until it's addressed (on protected branches)?

Multiple choicehard

What does a CODEOWNERS file do?

GitHub Code Review Quiz

5 questions to check what you learned.

  1. What should you read before reviewing the code itself?

    • The commit hashes
    • The repository's licence
    • The author's profile
    • The pull request's description

  2. Why use "Start a review" instead of single comments?

    • It's required
    • It hides your comments from the author
    • It sends all your comments together with one verdict, instead of a notification per comment
    • It approves automatically

  3. What does "nit:" usually mean at the start of a comment?

    • This is a serious bug
    • Not in this PR
    • Needs immediate testing
    • A small, optional point

  4. The author has fixed your requested changes. How do they ask you to look again?

    • Click re-request review next to your name
    • Open a new pull request
    • Close and reopen the PR
    • Delete your comments

  5. Which comment is the most helpful?

    • "Bad code."
    • "This runs a database query inside the loop, so 100 items means 100 queries. Could we load them all at once before the loop?"
    • "Why?"
    • "Rewrite this."

Related GitHub topics

08Pull RequestsPropose changes from a branch, review them, respond to feedback and merge with a pull request.10Forks & Open SourceFork a repository, keep your fork in sync with the original, and contribute to open-source projects through pull requests.15GitHub ActionsAutomate testing, checks and deployments with GitHub Actions workflows written in YAML.
Esc
↑↓ to navigateEnter to open