Handling review feedback: a practical Git & GitHub guide

Introduction

You've submitted a pull request, and now the review comments are rolling in. The natural instinct is to feel defensive or rush through fixes, but handling review feedback professionally is what separates junior developers from those who earn senior titles. Handling review feedback: a practical Git & GitHub guide means understanding that code review is a conversation, not a critique of your abilities. In this final installment of our 100-day series, we'll walk through the exact practices that keep your team's review process smooth, your PRs moving forward, and your professional reputation intact.

Why review feedback matters more than the code itself

A pull request isn't just about getting code merged. It's a checkpoint where your team's collective experience catches issues before production, shares knowledge across the codebase, and sets standards. When you ignore feedback or treat it as bureaucratic overhead, you signal that you're not aligned with the team's values. Conversely, when you engage thoughtfully with every comment, you build trust, improve the code quality, and often learn things that stick with you for years.

The stakes are real: we've all seen production incidents that a single careful review would have caught, and we've all experienced the compounding technical debt of code that bypassed scrutiny. Your approach to feedback directly impacts both the immediate PR and the long-term health of the system.

Thank reviewers: set the tone

Before diving into code changes, start your feedback response thread with genuine thanks. This sounds obvious, but it's remarkably rare in practice. A simple "Thanks for the thorough review" or "Appreciate the catch on the race condition" does two things: it acknowledges the reviewer's effort and sets a collaborative tone for the conversation.

If the feedback is particularly detailed or catches something subtle, say so explicitly. Reviewers spend their time on your code to help the team. Acknowledging that effort builds reciprocal goodwill. When you later submit a PR of your own work, reviewers remember who engaged professionally with their feedback.

In practice, this means your first comment on the PR after review should be something like:

Thanks for reviewing this. I'll address the points below and push an update shortly.

Then walk through each item. This front-loaded gratitude prevents feedback responses from feeling defensive or robotic.

Resolve or explain each comment: be explicit

Every comment deserves a response. If the reviewer suggests changing error handling, don't silently rewrite it and push; explain what you changed and why. If you disagree with a suggestion, explain your reasoning. This transparency keeps reviewers in the loop and prevents the same feedback from appearing three cycles later.

Let's say a reviewer comments on your Go error handling:

This wraps errors but doesn't include the original context. Consider using fmt.Errorf with %w to preserve the error chain.

You have three options:

1. Agree and implement: Update your code, push a commit, and reply: "Updated in the latest commit. Used %w to preserve the error chain so debugging stack traces are clearer."
2. Agree but provide context: "You're right for most cases, but here we deliberately discard the original error because it contains sensitive database details. We log it separately on the server side. Updated comment to clarify."
3. Respectfully disagree: "I considered that approach. In this case, we're catching and rethrowing in multiple layers, and the explicit message is clearer for our logging. Happy to discuss further if you think the trade-off isn't worth it."

In all three cases, the reviewer knows exactly where you stand. They're not left wondering if you read the comment or forgot about it.

When you have multiple comments, use GitHub's inline reply feature to address each one in context. If there's a common thread (say, three comments about the same architectural decision), consider grouping them in a single response at the PR level.

Push follow-up commits for easy re-review

After feedback, you need to update your code. The question is: how do you structure those updates so reviewers can quickly see what changed?

The key principle is make the reviewer's job easy. Push new commits with clear messages that indicate they're in response to feedback. Don't force-push and rewrite history unless your team explicitly uses that practice. A linear history of "address feedback" commits helps reviewers use git diff to see exactly what changed.

For example, after addressing three review comments, your history might look like:

2a9f1c3 (HEAD) Address review feedback: improve error handling and add validation
9e4d2f1 Address review feedback: update database query performance
7b8c5e2 Add user authentication endpoint
6a3f9d1 Refactor session management

Reviewers can then run:

git diff 7b8c5e2..HEAD

to see all changes since the initial implementation. Or they can inspect individual "feedback" commits to understand your thought process.

Avoid these patterns:

• Rebasing without warning: If you rewrite history, tell reviewers. Use "force-push" only if your team's workflow supports it; otherwise, it creates confusion.
• One monster "fix everything" commit: Push commits that address distinct feedback items separately if possible. This makes it easier to trace decisions.
• No commit messages: "update" or "fixes" tells reviewers nothing. Use "Address review: add bounds checking to array access" so they understand the intent before reading code.

If your PR has accumulated several feedback cycles, your commit log tells a story. That story is valuable for future developers (and your future self) who read the code and wonder why certain decisions were made.

Discuss big disagreements in person

Sometimes review feedback isn't a small fix—it's a disagreement about architecture, performance trade-offs, or priorities. Writing back and forth in GitHub comments can spiral into exhausting threads where both parties talk past each other.

When you sense a fundamental disagreement, escalate to synchronous communication. Slack, a 15-minute video call, or even walking to someone's desk works better than GitHub threading. Here's why:

• Tone is lost in text; misunderstandings multiply.
• Complex trade-offs are easier to explore verbally.
• You often discover you agree on the goal but differ on the path.
• Real-time conversation builds relationship and understanding.

For example, if your reviewer says "This approach doesn't scale to 10,000 concurrent users" and you believe it does, don't argue via comments. Instead, say:

I see the concern. Before I revise, can we chat for 10 minutes? I want to walk you through the load test results I ran locally and understand the specific scalability issue you're seeing.

After the call, you might discover the reviewer was thinking of a different bottleneck, or you'll learn something that genuinely improves your design. Either way, you've converted potential conflict into collaboration. Then document the decision in a follow-up comment so the PR thread captures the reasoning.

This is particularly important in senior roles. Junior developers often defer too quickly to feedback; senior developers sometimes double down too hard. The professional middle ground is: listen, understand the concern, discuss trade-offs respectfully, and make a principled decision together.

Common mistakes

Defensive responses

Comments like "that's just how I prefer to write it" or "it works fine" don't move the conversation forward. Even if you disagree, frame your response around code principles, team standards, or concrete reasons. Replace "it works fine" with "this approach handles the edge case of concurrent writes by using a mutex, which adds latency but prevents data corruption."

Ignoring minority comments

If one reviewer out of three raises a concern, don't dismiss it as a minority opinion. Investigate why they flagged it. Often they've spotted a real issue that the others missed, or there's a misunderstanding you need to clear up.

Pushing commits without updating the thread

You push a new commit addressing feedback but don't comment. Reviewers don't know if you're still working, forgot, or what. Always drop a note: "Pushed a fix for the null pointer issue in the latest commit."

Re-opening old debates

If a reviewer previously approved a pattern and now questions it, don't say "you already approved this once." Instead, acknowledge the new concern might reveal something you all missed. This keeps the review process constructive rather than adversarial.

Key takeaways

• Begin feedback responses with genuine thanks. It sets a collaborative tone and builds team culture.
• Address every comment explicitly, whether you agree, disagree, or need clarification. Silence creates ambiguity.
• Push follow-up commits with clear messages that explain your changes, making re-review fast and traceable.
• When fundamental disagreements emerge, move to synchronous communication. Asynchronous threading can breed misunderstanding and frustration.
• Frame all responses around principles, team standards, and concrete trade-offs, never defensiveness or personal preference.
• Remember that reviewers are investing time to strengthen the codebase. Engaging professionally with feedback builds the respect that accelerates your career.