Code Review

GitHub code review turns a PR diff into a structured conversation with formal states, line-level threads, and committable suggestions. It is the mechanism that gates whether a change merges, so the review states are not just opinions — under branch protection they decide what lands.

The features that make review effective are the ones that batch feedback, make changes one click to apply, and keep approvals honest as the branch moves. Skip them and review degrades into a stream of notification emails and rubber-stamp approvals.

Review States

A review is submitted as one of three states: Comment leaves feedback without a verdict, Approve signals the change is good to merge, and Request changes blocks it. Under branch protection a single Request changes can hold the merge button until that reviewer explicitly re-reviews.

That stickiness is the point and the trap. Request changes does not clear itself when the author pushes a fix — the blocking reviewer has to come back and re-review, so leaving one before disappearing stalls the PR indefinitely.

Review Threads

Comments attach to a line or a range of lines and form threads that can be resolved once addressed. The key habit is to "Start a review" so comments batch into one submission, rather than firing each comment individually and sending the author a separate notification per line.

Resolving threads explicitly is what makes the unresolved count meaningful. When every addressed thread is marked resolved, the remaining count is real outstanding work, not a mix of done and not-done that no one trusts.

Suggested Changes

A suggestion block proposes exact replacement code that the author commits with one click, and multiple suggestions can be batched into a single commit. It is the difference between "this should be 5, not 3" — which the author has to translate into an edit — and a change they apply directly.

For any concrete code change, a suggestion is strictly better than prose: it removes the chance of the author mis-applying the edit and it records the reviewer's exact intent in the diff.

Re-review and Stale Approvals

After an author addresses feedback, they request a re-review to pull the reviewer back in. When "dismiss stale approvals" is configured, a new push automatically invalidates prior approvals, so the version that merges is the version that was actually approved.

Without that setting, a PR approved at commit A can merge with a later commit B that no one reviewed. The stale-approval dismissal closes exactly that gap between what was approved and what lands.

Review Assignment

A CODEOWNERS file auto-requests the right reviewers based on which paths a PR touches, so the correct people are pulled in without the author having to remember them. Teams can be assigned with round-robin or load-balancing so review work spreads evenly, and a required-reviewer count enforces how many approvals a merge needs.