The Hook (The "Byte-Sized" Intro)
Getting review feedback isn't a setback — it's the process working exactly as designed. Even the best engineers get "request changes" on their PRs. The skill isn't writing perfect code the first time; it's responding to feedback quickly, cleanly, and without ego. Here's the playbook for turning review comments into merged PRs.
📖 What is Handling Review Feedback?
When reviewers leave comments on your PR, you need to address them, push updates to the same branch, and re-request review. The PR updates automatically with your new commits — no need to open a new one.
Conceptual Clarity
The feedback loop:
| Step | Action | Detail |
|---|---|---|
| 1 | Read all comments | Don't react one by one — get the full picture first |
| 2 | Ask for clarification | If a comment is unclear, ask before guessing |
| 3 | Make changes | Address each comment in your code |
| 4 | Commit + push | Push to the same branch — PR updates automatically |
| 5 | Reply to comments | Mark what you fixed, explain decisions you kept |
| 6 | Re-request review | Notify reviewers that fixes are ready |
Commit strategies for feedback:
- Separate fixup commits: One commit per review comment → easy for reviewer to verify
- Amend + force-push: Rewrite history to keep a clean commit log → harder to re-review
- Squash at merge: Keep fixup commits separate during review, squash when merging
Real-Life Analogy
Handling review feedback is like responding to an editor's red-pen comments on a manuscript. You read all the notes, make revisions on the same document (not a new one), reply to each comment explaining what you changed, and hand it back for final approval.
Visual Architecture
Why It Matters
- Speed: Quick feedback turnaround gets your PR merged faster.
- Professionalism: Responding thoughtfully shows maturity and team-first thinking.
- Learning: Every review comment teaches you something about the codebase or craft.
- Clean PRs: Proper fixup-and-push keeps the PR history readable.
Code
# ─── Address feedback with separate commits ───
# Reviewer said: "Add null check in getUser()"
git add src/user.js
git commit -m "Add null check in getUser per review"
# Reviewer said: "Rename variable for clarity"
git add src/utils.js
git commit -m "Rename 'x' to 'userCount' per review"
# Push all fixes at once
git push
# ─── Address feedback with fixup commits (for squash later) ───
git commit --fixup=abc1234 # References the original commit
git push
# At merge time: GitHub squashes automatically
# ─── Address feedback by amending (clean history) ───
git add src/user.js
git commit --amend --no-edit # Add to latest commit
git push --force-with-lease # Safe force-push
# ─── Mark comments as resolved on GitHub ───
# Click "Resolve conversation" on each addressed comment
# ─── Re-request review ───
# Click "Re-request review" button next to reviewer's name
# OR: gh pr review --request-review reviewer-nameResponding to Comments
| Comment Type | How to Respond |
|---|---|
| "Fix this bug" | Fix → commit → reply "Fixed in abc1234" |
| "Consider doing X instead" | Either implement X or explain why your approach is better |
| "Nit: rename this variable" | Fix it quickly — don't argue over style |
| "I don't understand this" | Add a code comment or improve naming to make it clearer |
| "This could be a security issue" | Fix immediately — security comments are always priority |
Key Takeaways
- Push fixes to the same branch — the PR updates automatically.
- Read ALL comments before fixing — get the full picture first.
- Reply to every comment, even if just "Done" or "Fixed in [commit]."
- Re-request review after pushing fixes so reviewers are notified.
Interview Prep
-
Q: How do you handle review feedback you disagree with? A: Respond respectfully with your reasoning. Provide context, benchmarks, or documentation supporting your approach. If the reviewer still insists and it's not a critical issue, consider implementing their suggestion — team cohesion matters more than being right about a minor point.
-
Q: Should you amend your commits or create new ones for review feedback? A: Both approaches work. Creating new "fixup" commits makes it easy for reviewers to see only the changes. Amending and force-pushing keeps a clean history. Many teams prefer fixup commits during review and then squash at merge.
-
Q: What should you do if you don't understand a review comment? A: Ask for clarification. Reply to the comment with a specific question. Don't guess and implement something wrong — it wastes both your time and the reviewer's time.