Code review is the part of the workflow where another person examines the proposed change before it is merged.
What review can include
A reviewer may:
- approve the pull request
- request changes
- leave comments or questions
The goal is not only to catch bugs. Review also helps teams check clarity, consistency, and maintainability.
What responding to review looks like
In a normal workflow, responding to review means:
- reading the feedback carefully
- making the needed updates locally
- committing the changes
- pushing more commits to the same branch
Because the pull request follows the branch, those follow-up commits appear in the existing review flow.
A useful beginner mindset
Treat review as part of finishing the work, not as a separate interruption.
The change is not really done when the first pull request is opened. It is done when the final reviewed version is ready to merge.
What not to optimize for first
At the beginning, do not worry about mastering every possible review feature.
Focus on the simple path:
- read feedback
- make the change
- push the update
- confirm the reviewer can see the new version
That is the core loop that matters most.