A 1,500-line pull request does not take ten times longer to review than a 150-line one. It takes longer than that, because nobody starts it. Reviewers see the line count, decide they need a free afternoon they do not have, and the PR sits. Small PRs break that cycle.
Why big PRs stall#
Three things happen with a large diff:
- Reviewers postpone it, so feedback arrives days late, after you have mentally moved on.
- When the review finally happens, it is shallow - nobody can hold 40 files in their head, so real bugs hide in the middle of the diff.
- Merges get riskier, because a PR that touches everything conflicts with everything.
A PR under a few hundred lines gets read the day it opens, and it gets read properly.
Splitting a Laravel feature#
Take a typical feature: a migration, a model, a controller, routes, a form request, views, tests. That feels atomic, but it usually splits cleanly:
- Migration and model first - the schema is reviewable on its own.
- The read path next - list and show endpoints with their tests.
- The write path last - create, update, delete, and validation.
Each PR is deployable, each review is quick, and if the write path turns out to be the wrong design, you have not merged it yet. If later PRs depend on earlier ones, use stacked branches: branch the second PR off the first, and retarget it to main once the first merges.
Keeping PRs small day to day#
- One idea per PR. If the description needs an “and also”, it is two PRs.
- Split mechanical changes (a rename across 30 files, a Pint run) from behavioral ones, so the behavioral diff stays readable.
- Tidy commits before opening the PR so the reviewer reads your intent, not your process - see Tidying Commits Before You Open a Pull Request.
- Write a description that says what to look at first - Writing a Good Pull Request Description covers that.
The habit compounds: reviewers who trust your PRs to be small stop dreading them, and the whole team’s queue moves. Pair it with the review-side habits in Code Review Habits That Actually Catch Bugs and the review round trip gets short enough to feel like pair programming at a distance.
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.
