Pull Request Practices
Pull request practices are the habits that make review fast and reliable. Most of them reduce to one lever — size — because review quality collapses once a diff runs past a few hundred changed lines and reviewers start skimming instead of reading.
The rest is communication and timing: a description that explains intent, a turnaround norm that keeps branches from rotting, and a way to split work that is too big to review in one sitting. None of it is GitHub-specific; it applies to any platform with a review step.
PR Size
Small PRs get reviewed faster and more thoroughly because a reviewer can hold the whole change in their head at once. Past a rough ceiling of a few hundred changed lines, attention drops off and approvals turn into rubber-stamps that catch nothing.
The cure is to make each PR one coherent change. If a task naturally produces a thousand lines, that is a signal to split it, not to ask the reviewer to read harder.
The Description
A useful description answers what changed, why, and how to test it, with screenshots for anything visual. Linking the issue with Closes #N ties the PR to the discussion that justified it and closes the issue automatically on merge.
The why is the part the diff cannot show. A reviewer who has to reverse-engineer intent from the code reviews slower and misses the cases the change was meant to handle.
Review Turnaround
Treat same-day first review as a team norm. A PR that sits for several days is not neutral — main moves underneath it, the branch develops conflicts, and the author ends up redoing work that already merged.
Fast turnaround is cheaper than it looks, because the cost of a stale PR is paid in conflict resolution and context-switching later, not in the few minutes a prompt review takes now.
Stacked PRs
When a change is genuinely large, split it into a dependent chain of small PRs — a stack — where each builds on the one below. Each link stays reviewable on its own, and the stack merges bottom to top.
Managing a stack by hand is painful: rebasing the bottom forces manual fixups all the way up. Tooling like Graphite, spr, and ghstack exists precisely to automate that propagation.
Self-Review and Draft Discipline
Read your own diff before requesting a human. Self-review catches the obvious — a stray debug line, a renamed variable missed in one spot — that would otherwise burn a reviewer's attention. Keep the PR in draft until CI is green so no one reviews a change that does not even build.
- Opening a 2,000-line PR, so reviewers skim and approve it — which defeats the entire purpose of review.
- Writing a description that says only "fixes bug", forcing the reviewer to reverse-engineer intent from the diff and miss the why.
- Letting a PR sit four days for review, so
mainmoves, the branch conflicts, and the author redoes work that already merged. - Bundling a refactor and a behavior change in one PR, so the reviewer cannot tell which lines are the real change and which are noise.
- Hand-managing a stack of dependent branches without tooling, so rebasing the bottom forces manual fixups all the way up the stack.
- Keep PRs under a few hundred changed lines and split larger work into a stack of dependent PRs.
- Write the description as what, why, and how-to-test, and link the issue with
Closes #N. - Set a team norm of first review within one business day and track it with a PR dashboard.
- Separate pure refactors from behavior changes into distinct PRs so each diff is reviewable on its own.
- Self-review your own diff before requesting review, to catch the obvious before a human spends time on it.
Knowledge Check
Why does a 2,000-line PR degrade review quality?
- Reviewers cannot hold the whole change in their head, so they skim and rubber-stamp, catching little
- GitHub caps the number of inline comments allowed on a large diff, so detailed feedback becomes impossible
- Large diffs always contain more bugs per changed line than small ones, so the defect rate rises mechanically
- It does not — larger PRs are reviewed more carefully because they look important
What is the concrete cost of letting a PR sit four days before review?
mainmoves underneath it, the branch conflicts, and the author redoes work that already merged- The PR is auto-closed and its branch deleted once it crosses a built-in review deadline on GitHub
- The commits lose their author attribution, reattributing the work to whoever finally merges the branch
- Nothing — a PR's age has no effect on its mergeability, since the diff is recomputed fresh at merge time
When do stacked PRs beat one large PR?
- When a change is too big to review at once, a dependent chain keeps each link small and reviewable
- Never — a single PR is always easier to manage, since one branch avoids the rebase churn a stack creates
- Only when the change touches exactly one file and you want a separate PR per commit in that file
- Only for documentation changes, never for code, where each section can land as its own small PR
Why should a refactor and a behavior change go in separate PRs?
- So the reviewer can tell which lines are the real behavior change and which are mechanical noise
- Because GitHub bills per PR by change type, charging more for a combined refactor-plus-behavior diff
- Because refactors cannot be reviewed at all and have to be merged separately without any review step
- Because mixing them prevents the branch from ever merging until the two kinds of change are pulled apart
You got correct