A pull request review is the formal decision a reviewer attaches to a pull request, approve, request changes, or comment, plus everything the platform does with that decision: unlocking or blocking the merge button, notifying the author, and recording who signed off on what. It is easy to conflate "reviewing a pull request," the activity of reading a diff and leaving feedback, with "a pull request review," the specific artifact GitHub or GitLab creates when that feedback is submitted. The distinction matters because only the second one has any effect on whether code can actually merge.
What changed in 2026
- Required reviews became closer to universal on any repository with more than one contributor, as branch protection and rulesets moved from an advanced setting to a default recommendation in most platform onboarding flows.
- CODEOWNERS-based routing got more granular, letting teams require sign-off from specific owners only on the paths that changed, instead of requiring the same reviewers for every PR regardless of what it touches.
- AI review tools now post as an additional reviewer on many teams, but their comments and approvals typically do not satisfy a required-human-reviewer rule unless a team deliberately configures it that way.
The three review states
Every review submitted on GitHub or GitLab is one of three states, and only one of them blocks anything by default.
| State |
What it does |
Blocks merge? |
| Comment |
Leaves feedback with no verdict |
No |
| Approve |
Signals the reviewer is satisfied |
Counts toward required approvals |
| Request changes |
Signals the reviewer found blocking issues |
Yes, until the same reviewer approves or dismisses it |
A comment-only review can contain the most detailed, critical feedback in the world and still not stop a merge. If feedback needs to be addressed before code ships, the reviewer has to select request changes, not just write a strongly worded comment.
How review becomes a gate, not a suggestion
By itself, a review is just data attached to a pull request. It becomes an actual gate through branch protection rules or rulesets configured on the target branch: require a set number of approvals, require review from code owners, dismiss stale approvals when new commits are pushed, require conversation resolution before merge. Without at least one of these configured, a reviewer can request changes and the author can still merge anyway on most default settings — the review is a strong social signal, not a lock.
Roles in a pull request review
- Author — opens the PR, responds to feedback, pushes updates.
- Reviewer — anyone requested or anyone with repository access who chooses to review; their verdict counts toward required approvals only if they are on the required list.
- Required reviewer / code owner — a reviewer whose approval a branch protection rule specifically needs, often assigned automatically through a CODEOWNERS file based on which paths changed.
- Merge authority — whoever the platform allows to click merge once every required check and review is satisfied; this can differ from the author.
Synchronous versus asynchronous review
Most pull request review happens asynchronously: the author opens the PR, reviewers get to it within their own schedule, and comments go back and forth over hours or days. Some teams run synchronous review instead, where the author and reviewer look at the diff together in a call, trading a slower per-PR cycle for faster resolution of any disagreement. Neither is strictly better; async scales across time zones, sync resolves ambiguity faster when the change is unusually risky or contentious. A synchronous review session looks a lot like a brief mob programming session focused on evaluating code instead of writing it.
FAQ
Does every pull request need a review?
Only if the branch protection rule for that branch requires one. Without a rule, review is optional and depends entirely on team discipline, which is why most teams with more than one contributor turn on a required-reviewers rule.
What is the difference between approve and comment?
Approve counts toward a required-approvals rule and signals the reviewer is satisfied enough to merge. Comment leaves feedback with no verdict attached and does not count toward anything.
Can an author merge their own pull request?
Usually yes, unless a rule specifically requires review from someone other than the author. Self-merging with no other reviewer defeats the purpose of the review step, which is why most teams disallow it through branch protection.
Does requesting changes block the merge forever?
Only until it is resolved, either the same reviewer changes their review to approve, or in some platform configurations a new commit or an admin override clears the block. It does not expire on its own.
Where to go next