Lesson 12 of 30

Code Review as a Git Workflow

Q: How do you handle Git history while addressing PR review feedback — when do you add a new commit versus amend, and what has to happen differently when you push each?

A strong answer covers: New commits preserve a reviewable trail against what the reviewer already saw; amending erases it by changing the commit's hash; Amend is reasonable for commits nobody has reviewed yet, or right before final merge cleanup; Amending a pushed, already-reviewed commit requires a force-push, and --force-with-lease over plain --force to avoid clobbering someone else's work; Resolving a review thread on GitHub is separate bookkeeping from actually pushing the fix.

Review comments aren't a to-do list you close in your head — they're Git operations. New commits vs. amend, when to force-push, and how to actually resolve a thread.

15 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

No quiz for this one — it's a practical topic

This topic is about judgment and practical tradeoffs more than a single right answer — a mock interview is the better way to test yourself on it.

Be interviewed on this →

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Code Review as a Git Workflow

What interviewers actually ask about this, and what a strong answer has to cover.

How do you handle Git history while addressing PR review feedback — when do you add a new commit versus amend, and what has to happen differently when you push each?

A strong answer covers

New commits preserve a reviewable trail against what the reviewer already saw; amending erases it by changing the commit's hash
Amend is reasonable for commits nobody has reviewed yet, or right before final merge cleanup
Amending a pushed, already-reviewed commit requires a force-push, and --force-with-lease over plain --force to avoid clobbering someone else's work
Resolving a review thread on GitHub is separate bookkeeping from actually pushing the fix

Likely follow-ups

What specifically does --force-with-lease check that plain --force doesn't?
If a teammate pushed a commit to the same branch right before your force-push, what happens with --force-with-lease versus --force?
Once a PR is approved and about to merge, does it still matter whether you used new commits or amends along the way?

Practice these with the AI interviewer →

The plain-language idea

Once a PR is open, review feedback has to turn into Git history somehow. There are two honest ways to do that: add a new commit on top that addresses the feedback, or amend an existing commit so the fix is folded into it as if it had always been there. Neither is universally correct — they trade off reviewability against final history cleanliness, and picking the wrong one for the situation is a common source of friction with reviewers.

New commits keep a paper trail: the reviewer can see exactly what changed in response to their specific comment, using GitHub's "changes since last review" diff view. Amending destroys that trail — the commit reviewers already looked at literally no longer exists, replaced by a new one with a different hash — which is great for final history cleanliness but means the reviewer has to re-review the whole file instead of just the delta.

See it in a real thing: responding to review feedback

A reviewer leaves a comment: "this should early-return on the null case instead of nesting." You fix it as a new commit, so the reviewer can see just that delta:

$ git add lib/parseUser.ts
$ git commit -m "review: early-return on null user instead of nesting"
[fix/parse-user-null 4e8a1c2] review: early-return on null user instead of nesting
 1 file changed, 4 insertions(+), 6 deletions(-)

$ git push

No -u needed this time — the branch already tracks origin/fix/parse-user-null from your first push, so a bare git push knows exactly where to send it. GitHub appends the new commit to the PR and shows the reviewer a small, focused diff instead of the whole file again.

Now compare: suppose the very last commit you made — the one still open for review, not yet approved — has a typo in a variable name and nobody's reviewed that far yet. Amending is the right call here, because there's no review history worth preserving on a commit nobody has looked at:

$ git add lib/parseUser.ts
$ git commit --amend --no-edit
[fix/parse-user-null 9f3b7d1] review: early-return on null user instead of nesting
 1 file changed, 5 insertions(+), 6 deletions(-)

--amend rewrites the last commit — same message (--no-edit keeps it), new content, and critically, a new hash. That's the part that requires a force-push, because the remote branch still points at the old commit and a normal push would be rejected as a non-fast-forward:

$ git push --force-with-lease

--force-with-lease is the safer force-push: it refuses to overwrite the remote branch if someone else pushed to it since you last fetched, protecting a reviewer's in-flight comments or a co-author's commit from silently vanishing. Plain --force has no such check.

Once a reviewer's comment is actually addressed, resolve the thread in GitHub's review UI — click "Resolve conversation" on that comment. This isn't a Git operation at all, it's GitHub bookkeeping layered on top, but it's what lets a reviewer see at a glance which of their comments still need action versus which are done, especially on a PR with dozens of threads.

What people usually miss

Watch out

Amending after a reviewer has already looked at the commit erases their reference point. GitHub's "Files changed" tab shows a diff against what the reviewer last saw; amend that commit and their prior comments can end up orphaned or attached to a diff that no longer exists in that form.
A force-push to a shared review branch is scarier than a force-push to your own throwaway branch. If a reviewer or co-author pushed a commit to the same branch since you last pulled, --force silently discards it. --force-with-lease is the default you should reach for on anything with more than one contributor.
Resolving a thread and addressing the feedback are two different actions. Clicking "Resolve" without pushing the actual fix just hides the comment from view — it doesn't make the code change happen. Push the commit first, resolve second.

The genealogy: this is restoring-and-undoing's amend, under review pressure

git commit --amend is the exact same command covered in the restoring-and-undoing concept — rewriting the last commit instead of creating a new one — the only new thing here is the consequence: once that commit has already been pushed and reviewed, amending means force-pushing over history someone else has seen, which is a much higher-stakes version of the same operation.