Code Review on GitHub: Leaving Comments, Suggestions, and Requesting Changes

Code review is one of the core activities a pull request exists to enable, and GitHub provides a rich set of tools specifically built for it — going well beyond simply reading a diff. This lesson covers inline comments, the especially powerful 'suggested changes' feature, and the three formal review outcomes a reviewer can choose from.

Learning Objectives

Leave an inline comment on a specific line within a pull request's diff.
Propose a suggested change that the author can apply with a single click.
Understand the difference between the three review outcomes: comment, approve, and request changes.
Recognize how a request-changes review interacts with branch protection rules.

Key Terms to Know Before Reviewing Code on GitHub

Inline comment: A comment left directly on a specific line (or range of lines) within a pull request's diff, keeping feedback precisely attached to the relevant code.
Suggested change: A special type of inline comment containing a proposed code replacement, which the pull request's author can apply directly with a single click, automatically creating a commit.
Review outcome: The formal conclusion of a code review, chosen as one of three options — Comment, Approve, or Request changes — submitted alongside any inline comments.
Request changes: A review outcome explicitly indicating the reviewer does not think the PR is ready to merge as-is, often blocking merging (depending on branch protection rules) until addressed.

How Code Review on GitHub Actually Works

The most fundamental code review tool is the **inline comment**: clicking directly on a specific line (or selecting a range of lines) within a pull request's 'Files changed' tab opens a comment box tied precisely to that location. This is far more useful than a general comment on the PR as a whole, since it keeps feedback tightly attached to the exact code it refers to, and lets both the author and reviewer have a threaded, focused discussion right there in context.

A particularly powerful variant of the inline comment is the **suggested change**. Rather than just describing what should change in prose, a reviewer can propose the *exact* replacement code, formatted in a special suggestion block:

```
```suggestion
const discount = calculateBulkDiscount(quantity);
```
```

When rendered, GitHub shows this as a clear 'before/after' diff directly within the comment, with a prominent **'Commit suggestion'** button. If the pull request's author (or anyone with write access) clicks this button, GitHub automatically creates a new commit applying exactly that change to the branch — no need for the author to manually copy the suggestion, switch to their editor, make the edit, and push a new commit themselves. This dramatically speeds up addressing small, precise feedback like typos, minor logic corrections, or style adjustments.

Once a reviewer has left whatever comments (and suggestions) they intend to, they submit their review with one of three formal **outcomes**:

- **Comment**: Feedback is left, but no formal approval or rejection is indicated — appropriate for general questions, discussion, or feedback on a PR you're not the primary decision-maker for.
- **Approve**: The reviewer explicitly signals the pull request looks good and is ready to merge, as far as they're concerned. If a repository's branch protection rules (Module 4) require a minimum number of approvals, this contributes toward that requirement.
- **Request changes**: The reviewer explicitly signals the pull request is *not* ready to merge in its current state, typically because of specific issues raised in the accompanying comments. Critically, if branch protection rules require reviews, a 'Request changes' review generally **blocks merging** until the reviewer (or another reviewer) either changes their review to an approval, or the author pushes new commits addressing the feedback and the same reviewer re-reviews and approves.

This formal distinction matters for team process: 'Comment' keeps a conversation open without technically blocking anything, while 'Request changes' is a deliberate, technically enforced signal that specific concerns must be addressed before the code can be merged — an important tool for maintaining quality standards, but one that should be used thoughtfully rather than for minor stylistic preferences that don't genuinely warrant blocking a merge.

GitHub Code Review Tools: Visual Walkthrough

Draw a rendered PR diff snippet with a specific line highlighted, showing a comment thread bubble attached to it containing: 'Reviewer: Consider using calculateBulkDiscount() here instead' followed by a suggestion block showing a green +/- before-after code snippet with a 'Commit suggestion' button. Below, draw three labeled buttons representing the review submission options: 'Comment (feedback only, no formal verdict)', 'Approve (green checkmark, contributes to required approvals)', 'Request changes (red icon, blocks merging until resolved, per branch protection rules).'

GitHub Review Outcomes: Quick Reference Table

Review Outcome	Signals	Effect on Merging (with required reviews)
Comment	General feedback or questions, no formal verdict	No effect — does not block or approve
Approve	The PR looks good and is ready to merge	Counts toward any required minimum approvals
Request changes	The PR is NOT ready to merge as-is	Typically blocks merging until resolved and re-reviewed

Writing a Suggested Change: Syntax and Examples

# Example of a suggested change left as an inline comment on a specific diff line
# (written directly in GitHub's web comment box, not a local Git command)

This calculation duplicates logic already in `calculateBulkDiscount()`. Consider reusing it:

```suggestion
const discount = calculateBulkDiscount(quantity);
```

# If the author clicks "Commit suggestion", GitHub automatically creates a new commit
# on the PR's branch applying exactly this change — equivalent to:
git add checkout.js
git commit -m "Apply suggestion from code review"
git push

Breaking Down the Code Review Example

The suggestion block shows the exact Markdown syntax (` ```suggestion `) a reviewer would use to propose a precise code replacement, rendered by GitHub as a clear before/after comparison. The final commands illustrate what happens behind the scenes when the author clicks 'Commit suggestion' — GitHub performs the equivalent of staging, committing, and pushing that exact change automatically, saving the author from manually reproducing a small, precisely specified edit.

How Code Review Is Practiced on Real Engineering Teams

Suggested changes are extremely popular for addressing small, unambiguous feedback — typos, minor formatting issues, simple logic corrections — since they let an author resolve feedback with a single click rather than a full manual edit cycle.
Many teams have explicit, documented norms around when 'Request changes' is appropriate, discouraging its use for minor stylistic preferences that don't genuinely warrant blocking a merge, to avoid unnecessary friction.
Branch protection rules requiring at least one or two approvals before merging (Module 4) are extremely common on professional teams, making the Approve outcome a technically meaningful, not just social, part of the merge process.
Some teams use the 'Comment' review outcome deliberately for optional, non-blocking feedback (like style suggestions or 'nice to have' ideas), explicitly distinguishing it from a 'Request changes' review reserved for things that must be fixed.

GitHub Code Review Interview Questions and Answers

Q1. What is a suggested change on GitHub, and how does it speed up addressing review feedback?

It's a special inline comment format where a reviewer proposes exact replacement code within a suggestion block. GitHub renders this as a clear before/after diff with a 'Commit suggestion' button, letting the PR's author apply the exact change with a single click, automatically creating a commit, rather than manually reproducing the edit themselves.

Q2. What is the difference between the three review outcomes on GitHub: Comment, Approve, and Request changes?

Comment leaves feedback without a formal verdict, appropriate for general discussion. Approve signals the PR looks ready to merge, contributing toward any required minimum approvals. Request changes signals the PR is not ready to merge as-is, typically blocking merging (if branch protection rules require reviews) until the concerns are resolved and re-reviewed.

Q3. How does a 'Request changes' review interact with branch protection rules requiring approvals?

If a repository's branch protection rules require reviews before merging, an outstanding 'Request changes' review from any reviewer typically blocks the merge button entirely, even if other reviewers have approved, until that specific reviewer either updates their review to an approval or the concerns are otherwise resolved.

GitHub Code Review Quiz: Test Your Understanding

1. What does a 'suggested change' on GitHub allow a reviewer to do?

Automatically merge the pull request
Propose exact replacement code that the author can apply with a single click
Delete the pull request
Permanently lock the branch from further edits

Answer: B. Propose exact replacement code that the author can apply with a single click

Explanation: A suggested change lets a reviewer specify the exact proposed code, which GitHub renders as a clickable, applicable suggestion that automatically creates a commit if accepted.

2. Which review outcome typically blocks a pull request from being merged, if branch protection rules require reviews?

Comment
Approve
Request changes
None of them can ever block merging

Answer: C. Request changes

Explanation: A 'Request changes' review explicitly signals the PR is not ready to merge, and under branch protection rules requiring reviews, this typically blocks the merge button until the concern is resolved and re-reviewed.

3. Does leaving a 'Comment' review outcome block a pull request from being merged?

Yes, always
No — it leaves feedback without a formal blocking verdict
Only if the repository is private
Only if the comment is on the first line of a file

Answer: B. No — it leaves feedback without a formal blocking verdict

Explanation: The Comment outcome is explicitly non-blocking, used for general feedback or discussion without indicating formal approval or rejection of the pull request.

Common Code Review Mistakes on GitHub

Leaving only general, non-inline comments on a PR as a whole, rather than attaching feedback to the exact relevant lines for clarity.
Writing out a proposed code change in prose instead of using the suggestion feature, missing the opportunity for the author to apply it with one click.
Using 'Request changes' for minor stylistic preferences that don't genuinely need to block a merge, creating unnecessary friction.
Not realizing an outstanding 'Request changes' review can block merging even after other reviewers have approved, until it's specifically resolved.

GitHub Code Review: Exam-Ready Quick Notes

Inline comments: attached to specific diff lines, keeping feedback precisely in context.
Suggested changes (```suggestion block): let the author apply an exact proposed edit with one click, auto-creating a commit.
Three review outcomes: Comment (non-blocking), Approve (counts toward required approvals), Request changes (typically blocks merging until resolved).
An outstanding 'Request changes' review generally blocks merging under branch protection rules, regardless of other approvals.

GitHub Code Review: Key Takeaways

GitHub's inline comments and suggested changes make code review feedback precise, actionable, and often resolvable with a single click.
The three formal review outcomes — Comment, Approve, Request changes — carry different technical and social weight, and should be chosen deliberately.
'Request changes' is a powerful, technically enforced tool for maintaining quality, best reserved for genuine blocking concerns rather than minor preferences.

Frequently Asked Questions About GitHub Code Review

Q1. How do I leave a comment on a specific line of code in a GitHub pull request?

Go to the pull request's 'Files changed' tab, click directly on the line (or select a range of lines) you want to comment on, and a comment box will open attached precisely to that location in the diff.

Q2. What is a 'suggested change' on GitHub?

It's a special type of inline comment where you propose the exact replacement code, using a suggestion block. GitHub renders it as a clear before/after comparison with a button the author can click to apply the change automatically, creating a commit without manual editing.

Q3. What is the difference between 'Approve' and 'Request changes' when reviewing a PR?

Approve signals the pull request looks ready to merge and counts toward any required minimum approvals. Request changes signals the PR is not ready as-is, and typically blocks merging (under branch protection rules requiring reviews) until the concerns are addressed and the reviewer re-reviews.

Q4. Does leaving a 'Comment' review block a pull request from merging?

No. 'Comment' is a non-blocking outcome used for general feedback or questions, without indicating a formal approval or rejection of the pull request.

Q5. Should I use 'Request changes' for every small suggestion I have?

Generally no. 'Request changes' is best reserved for genuine blocking concerns, since it can prevent merging until resolved. For minor stylistic preferences or optional suggestions, leaving a comment (or an approving review with optional suggestions) is usually more appropriate.

Summary

GitHub's code review tools center on inline comments — feedback attached directly to specific lines within a pull request's diff — and the especially powerful suggested changes feature, which lets a reviewer propose exact replacement code that the author can apply with a single click, automatically generating a commit. Once review comments are ready, a reviewer submits one of three formal outcomes: Comment (non-blocking general feedback), Approve (signals readiness to merge, counting toward any required minimum approvals under branch protection rules), or Request changes (explicitly signals the PR isn't ready, typically blocking merging until resolved and re-reviewed). Understanding this distinction — and using 'Request changes' deliberately rather than for minor preferences — is central to an effective, respectful code review culture.