In this lesson, you will learn how to refine your code in response to peer feedback by updating your existing feature branch to satisfy project requirements.
When a reviewer leaves comments on your Pull Request (PR), it is rarely a sign of failure; rather, it is a standard part of the collaborative development process. Once you have read the feedback, you don’t need to open a new PR. Instead, you keep working on your existing feature branch to incorporate the requested changes.
The Iteration Workflow
- Sync your local environment: Before making changes, ensure your local branch is up to date by performing a
git pullif there have been any remote updates. - Apply refinements: Open the necessary files in your code editor and apply the logic changes or cleanups requested by your reviewer.
- Commit your fixes: Once the code is adjusted, use
git addandgit committo save your changes. It is often helpful to keep these commits descriptive, such asgit commit -m "Address feedback: refactor validation logic". - Push to your remote branch: Because your feature branch is already tracking the remote, simply run
git push.
GitHub automatically detects these new commits and updates your existing PR. The review conversation remains linked to the original PR, allowing your reviewer to see exactly how you addressed their specific points.
Keeping It Clean
If you have several "fix-up" commits that clutter the history, you might consider using an interactive rebase (if your team workflow allows) to squash those small commits into the original ones before the final merge. However, for most iterative cycles, simply pushing your incremental commits is the standard way to show progress. Once you have pushed the fixes, you should reply to the reviewer's comments on GitHub to confirm the changes have been made. This signals to your team that the PR is ready for a second look.
Key Takeaway: Addressing review comments is an iterative process where you continue to push updates to your existing branch, allowing the Pull Request to reflect your progress until the code meets the project's standards.