What is a pull request review? The definition, the mechanics, and the point
Othman Shareef · October 10, 2026 · 4 min read · Code Review Glossary
A pull request review is a structured check of proposed code changes before they merge. A teammate reads the diff, leaves comments, and either approves the change or requests changes, so problems are caught while they are still cheap to fix.
How does a pull request review work on GitHub?
The author opens a pull request, a proposal to merge one branch into another, and requests reviewers, either by hand or automatically through code owner rules. The reviewer opens the Files changed tab, reads the diff, and attaches comments to specific lines. Comments can carry questions, requested fixes, or concrete suggestions the author can apply with one click. When the reviewer is done reading, they submit the review with one of three verdicts:
- Comment: feedback without a judgment, useful when you have notes but no authority or no strong opinion on merging.
- Approve: the change is good to merge as far as this reviewer is concerned.
- Request changes: the change should not merge until specific problems are addressed.
The author replies, pushes fixes, and asks for another look; each comment becomes a thread that gets resolved as the discussion settles. Branch protection rules can make all of this binding by requiring one or more approvals before the merge button works, which turns review from a courtesy into a gate.
What is a pull request review actually for?
Ask most developers and they will say finding bugs. That is part of it, but the research says it is not the biggest part. A well-known Microsoft study of code review in practice, Expectations, Outcomes, and Challenges of Modern Code Review, found that while defect finding is the top stated motivation, the actual outcomes lean toward code improvement, alternative solutions, and knowledge transfer. Review is how a team keeps a shared mental model of its own codebase: the reviewer learns what changed, the author learns what the team expects, and the code ends up readable by more than one person. We have written before about what reviews actually catch, and the honest answer is: fewer bugs than you hope, more understanding than you expect. Both are worth paying for.
What does a good pull request review look like?
A good review starts before the line-by-line reading: understand what the change is supposed to do, then check whether it does that, then look at how. Concretely, strong reviewers tend to do a few consistent things:
- Read the description and linked issue first, so the diff has context.
- Start with the riskiest files, not the first ones alphabetically.
- Comment with reasons, not just verdicts, and separate blocking from optional.
- Approve explicitly when satisfied instead of going silent.
If you want the full checklist treatment, we keep a practical code review checklist that covers correctness, tests, security, and readability in order. And when the diff is overwhelming, the problem is usually the pull request, not you; there are concrete tactics for reviewing large pull requests without skimming.
Where do pull request reviews go wrong?
Two failure modes cover most of it. The first is the rubber stamp: an approval given without real reading, which keeps the ritual while deleting the value. The second is the bottleneck: reviews that sit for days, punishing exactly the authors who split their work into small, reviewable pieces. Both have the same root cause, review treated as interruption rather than as first-class engineering work. Teams that treat it as the latter, with time carved out and expectations set, get the defect prevention and the shared understanding. Teams that do not get theater. The definition is simple; the discipline is the hard part.