Code Reviews, Inline Comments, Approvals and Changes Requested
Code Reviews, Inline Comments, Approvals and Changes Requested
Code reviews are the primary defense against software bugs, architectural rot, and security vulnerabilities. On GitHub, the Pull Request interface provides a comprehensive suite of review tools designed to foster collaborative learning and high engineering standards.
1. The Anatomy of a GitHub Code Review
When a teammate asks you to review their Pull Request:
- 1Navigate to the PR on GitHub and click the Files changed tab.
- 2Review the diffs line by line. Additions are green (
+), deletions are red (-). - 3Hover your mouse over any line of code and click the blue
+icon to start an inline comment.
+-----------------------------------------------------------------------------+ | Line 42: const userToken = jwt.sign(payload, "secret_key_123"); | +-----------------------------------------------------------------------------+ | [Review Comment] | | Hey! Let's avoid hardcoding secrets in source files. Can we use | | `process.env.JWT_SECRET` instead? | | | | [ Add single comment ] [ Start a review ] | +-----------------------------------------------------------------------------+
Single Comment vs. Starting a Review:
- Add single comment: Posts immediately and notifies the author right away. (Can be noisy if you leave 10 comments).
- Start a review (Recommended): Batches all your comments into a "Pending" draft. You can refine them and publish all comments at once when your review is complete.
2. Suggesting Code Changes Directly
Reviewers can do more than point out problems—they can provide ready-to-commit solutions! Click the Add a suggestion icon (+-) inside the comment box:
const userToken = jwt.sign(payload, process.env.JWT_SECRET, { expiresIn: '1h' });
The author can click Commit suggestion directly in GitHub, instantly incorporating your suggested code without switching back to their terminal!
3. Submitting the Review: The 3 Verdicts
Once you have examined the files, click Review changes in the upper right. Choose one of three verdicts:
| Verdict | When to Choose | Effect on PR |
|---|---|---|
| Comment | Submit general feedback or ask clarifying questions without giving approval | Leaves PR open; does not count toward branch protection approval quotas |
| Approve | You verified the code, tests pass, and it is ready to be merged | Marks the PR as approved green checkmark |
| Request changes | Critical bugs, security issues, or architectural flaws must be addressed | Blocks the PR from being merged until the author pushes fixes and requests re-review |
4. How the Author Addresses Review Feedback
If a reviewer requests changes:
- 1Do not open a new PR!
- 2Simply make the requested edits locally on your machine on that same feature branch.
- 3Commit the fixes and push:
- 1GitHub automatically appends the new commits to the existing Pull Request and updates the diff!
- 2In GitHub, click the Re-request review circular arrow icon next to the reviewer's name.
Practice Quiz
Syncing Upstream Repositories and Keeping Forks Updated
Continue learning with hands-on practice, examples, and exercises in the upcoming topic.
Related Lessons
Practice Quiz
Test your understanding of this lesson with 5 questions. Each question has one correct answer.