Module 9 Lesson 4: Handling feedback and requested changes

Your coworker just looked at your PR and clicked "Changes Requested." They found a bug or suggested a better way to write a function. This is a normal and healthy part of the engineering process.

In this lesson, we learn how to "Close the Loop"—from making the edits to getting that final approval.

---

1. Making the Updates

To update a PR, you don't close it and open a new one. You simply make new commits on your existing feature branch and push them.

# 1. Be on your feature branch
git switch feature/ui-fix

# 2. Make the requested changes in your editor
# 3. Commit the fixes
git commit -m "Fix: Handle null values as suggested by @sudeep"

# 4. Push to the server
git push

The PR on GitHub will automatically update to include your new commits.

---

2. Communicating the Fixes

Don't just push the code; tell the reviewer what you did.

• Reply to Comments: If someone left a specific comment, reply with "Fixed in abc1234" or "Good catch, I've updated the logic."
• Resolve Conversations: Many platforms allow you to mark a thread as "Resolved." Only do this once you have actually pushed the fix.
• Re-request Review: Once you've finished all the requested changes, click the "Re-request Review" button (the little circular arrow) to notify the reviewer that you are ready for a second look.

---

3. Dealing with Disagreements

What if you think the reviewer is wrong?

• Be Professional: Explain your reasoning clearly.
• Provide Links: Link to documentation or articles that support your approach.
• Involve a Third Person: If you are stuck in a "Stalemate," ask another senior developer to take a look. Two experts are better than one.

graph TD
    Request["Changes Requested"] --> Fix["Apply Fixes Locally"]
    Fix --> Push["Push to Feature Branch"]
    Push --> Reply["Reply to PR Comments"]
    Reply --> Notify["Re-request Review"]
    Notify -- "If Approved" --> Merge["Merge to main"]
    Notify -- "If more changes" --> Fix

---

Module 9 Practice Exercises

Let's practice the human side of Git:

1. The PR Draft: Write a PR summary for a feature that "Adds a User Profile Page." Include a "Why" section.
2. The Nitpick: Look at a piece of code and write a friendly "Nitpick" comment about a variable name.
3. The Revision: Imagine you push a fix for a PR. Write the comment you would leave for the reviewer to tell them you are ready for another look.
4. The Resolution: Practice "Resolving" a conversation after a fix is made.

Checkpoint: If you can explain the difference between a command and a question in a code review, you have mastered the Art of Collaboration!

---

Summary

In this lesson, we established:

• Updating a PR is done by pushing new commits to the same branch.
• Communication (replies, resolving threads) is key to a smooth review process.
• Professionalism and empathy are required even when you disagree with feedback.

Module Complete! You are now a team player who knows how to use Git as a social tool.

Next Module: Time for some magic. Welcome to Module 10: Git Tips and Tricks, where we’ll learn about aliases, the reflog, and how to recover from "The Middle of Nowhere."