Code Review on GitHub: Review Pull Requests Like a Professional

Code review is where good teams catch bugs, share knowledge and keep quality high. In this lesson you will review pull requests on GitHub, suggest changes, submit approvals, respond to feedback as an author and follow a practical review checklist.

---

👀 Why Code Review Matters

Code review means teammates read a change before it is merged. It catches bugs early, spreads knowledge across the team, keeps code consistent and is one of the best learning tools for juniors. On GitHub, code review happens inside pull requests.

For testers, reviewing pull requests is a chance to test earlier: spot missing edge cases, untested paths and risky changes before they reach a test environment.

---

🧭 Reviewing a Pull Request Step by Step

1. Read the PR title and description: what problem does it solve, and how was it tested?
2. Check that the CI checks are green.
3. Open the Files changed tab.
4. Comment on specific lines, suggest changes and ask questions.
5. Submit your review with one of three outcomes.

---

💬 Comment on Code

In Files changed, hover over a line and click the blue +:

• Click and drag over line numbers (or Shift-click) to comment on several lines.
• Write the comment, then choose Start a review (recommended) or Add single comment.

Start a review collects all your comments and publishes them together, so the author gets one notification instead of twenty.

Suggest a change directly

In the comment box, click the Add a suggestion button (the ± file icon). GitHub inserts the selected lines in a special “suggestion” block that you edit to the proposed code. The author can then click Commit suggestion, or batch several suggestions into one commit. This is perfect for small fixes such as typos, renamed variables or a better locator.

Useful helpers

• Tick Viewed on each file to track your progress in large PRs.
• Use the file filter and the file tree to focus on test files or one folder.
• Switch between unified and split diff view with the settings gear.
• Use @username to bring someone into a discussion.

---

✅ Submit the Review

Click Finish your review (or Review changes) and choose:

Option	Meaning
Comment	General feedback without approving or blocking
Approve	You are happy for it to be merged
Request changes	Something must be fixed before merging

With branch protection, a PR may require one or more approvals, and “Request changes” blocks the merge until the reviewer re-reviews. CODEOWNERS can request the right reviewers automatically.

---

🔁 As the Author: Responding to Review

1. Reply to each comment: agree, explain, or ask a question.
2. Push fixes to the same branch; the PR updates and outdated comments are marked as such.
3. Click Resolve conversation when a thread is settled (or let the reviewer do it, as your team prefers).
4. Click Re-request review next to the reviewer’s name when you are ready.

---

🧪 What to Look For: A Review Checklist

Area	Questions to ask
Correctness	Does it do what the description says? Any obvious bugs or edge cases missed?
Tests	Are there tests for the change? Do they test behaviour, not implementation details?
Test quality (automation PRs)	Stable locators, web-first assertions, no hard waits, independent tests (flaky tests)
Readability	Clear names, small functions, comments where the “why” is not obvious
Security	No secrets, tokens or personal data committed (.gitignore)
Scope	One purpose; unrelated changes moved to another PR
Docs	README, configuration and changelog updated if needed

---

🤝 Review Etiquette

❌ Avoid	✅ Prefer
“This is wrong.”	“This misses the empty-cart case. Could we add a test for it?”
“Why did you do this?!”	“What was the reason for the 5-second wait? Could expect(...).toBeVisible() replace it?”
Ten comments on style	Agree on a formatter and linter; let tools handle style
Blocking on personal preference	Prefix optional ideas with “nit:” (minor) or “optional:”
Reviewing 2,000 lines at once	Ask for smaller PRs

Praise good work too: “Nice use of a fixture here, much cleaner.”

---

🤖 Automating the Boring Parts

• CI checks run tests and linters on every PR (GitHub Actions).
• Required status checks block merging until they pass.
• Dependabot and code scanning add security reviews (security tools).
• GitHub Copilot can produce a first-pass review and PR summaries (Copilot); a human still owns the decision.

---

📝 Assignment

1. Ask a friend (or use a second GitHub account) to open a PR on your git-practice repository, or open one yourself.
2. Review it with Start a review: add at least one multi-line comment and one suggestion.
3. Submit a Request changes review, then fix the issues as the author and Re-request review.
4. Commit a reviewer’s suggestion directly from the PR page.
5. Approve the PR and merge it.
6. Write a short code review checklist for your own team or test project.

---

❓ FAQ

🤔 How do I review a pull request on GitHub?

Open the PR, go to Files changed, comment on lines (using Start a review), then click Finish your review and choose Comment, Approve or Request changes.

🤔 How do I suggest a change in a GitHub review?

In a line comment, click Add a suggestion, edit the proposed code, and submit. The author can apply it with Commit suggestion.

🤔 What is the difference between Comment, Approve and Request changes?

Comment gives feedback without a decision, Approve signals it is ready to merge, and Request changes asks for fixes and can block merging.

🤔 How do I re-request a review?

On the PR’s Conversation tab, click the circular arrow next to the reviewer’s name in the Reviewers section.

🤔 Should testers do code reviews?

Yes. Reviewing PRs lets testers spot missing test cases and risky changes early, and test automation code itself needs review like any other code.

---

🎯 Next Steps

• 🍴 Fork a Repository and Contribute to Open Source
• 🗂️ GitHub Issues, Labels and Projects
• 📘 Git and GitHub Tutorial: full course