The right answer to “how do I review a 2,000-line pull request” is usually “ask for three smaller ones” - and small pull requests get reviewed faster makes that case. But sometimes the split is not happening: it is a generated migration plus its fallout, a vendored update, a refactor that only makes sense whole. Here is how to review it honestly anyway.
Read in this order#
1. The description and the tests, before any source. The description tells you what the author thinks they did; the tests tell you what the code claims to guarantee. If either is missing, that is your first comment - reviewing code whose intent you are guessing is how subtle bugs get waved through.
2. The risky files, not the first files. Sort mentally by blast radius: migrations (see reviewing migrations), anything touching auth, money or deletion, config and deploy changes. These get your freshest attention and line-by-line reading. Controllers and views get pattern-level reading. Generated files, snapshots and lockfiles get a skim - nobody reviews composer.lock line by line, they verify it was regenerated (the lockfiles guide has the drill).
3. Commit by commit, if the commits are clean. A well-sequenced history is the author’s own explanation of the change - this is what tidying commits before review is for. If the commits are “wip”, “fix”, “fix fix”, abandon this step and read the full diff.
Give feedback that fits the size#
The failure mode of big reviews is binary: a defeated “LGTM” or a comment list so long it reads as hostility. The useful middle is sorting your comments:
- Blocking: correctness, security, data loss. Few of these, clearly marked.
- Worth discussing: design questions where you could be wrong.
- Not blocking: style and preference - say once, in one comment, not forty.
And say what you did: “read migrations and billing code line by line, skimmed the rest” is honest and lets the author ask a second reviewer for the parts you skimmed. Two honest partial reviews beat one pretend complete one.
The last word stays with prevention: the best large-PR review is the one that never has to happen because the next one got split.
Share this post
Keep reading
Branch Protection Rules That Stick
Three rules cover most of the risk on main: review required, tests green, no force-push. More than that tends to get routed around.
Merging vs Rebasing on a Small Team
Rebase to tidy your own branch, merge to combine into main. One sentence of policy saves a lot of history arguments.
Migrations in Code Review: What to Look For
A merged migration is a fact you cannot edit. The review checklist: reversible down(), safe defaults, indexes, and no data surgery in schema changes.
