GitHub pull request size: why small changes get real reviews
By Christophe Paka · Facts checked on 30 October 2026
A pull request lands with +891 -51 at the top and fifty files below it. Someone will approve it after a quick scroll, because the other choice is an afternoon lost in your branch. The approval is real. The reading was not.
That skim is where bugs slip through, and you pay for them later in production. GitHub pull request size is not a courtesy to your reviewer. It decides how much of the bug anyone finds. The figure below puts two published findings on one axis, so you can see where a change stops being readable.
How to read this figure
Read the two axes. The bottom axis counts the lines changed in one pull request, from 0 to 1000. The side axis is the share of defects reviewers find. The curve is a sketch of the shape, not a measurement. Only the quoted words and the Cisco numbers are data.
Find Google's two dots. Google's engineering guide says 100 lines is usually a reasonable size for one change, and 1000 lines is usually too large. That is an opinion, so the dots sit at drawn heights. Google also counts spread: 200 lines across 50 files is usually too large.
Look at the shaded band. The band from 200 to 400 lines is the most one sitting holds. In a Cisco study of 2,500 reviews, readers who took 200 to 400 lines over 60 to 90 minutes found 70 to 90 percent of the defects.
Read the pace note. The second box is about speed, not total time. Readers who went faster than 450 lines an hour did worse than average in 87 percent of reviews. A big pull request pushes your reviewer into that fast skim.
Follow the curve past 400. To the right of the band, the curve keeps falling. Each extra hundred lines buys less careful reading. That is why the size rule is a quality rule: the reader runs out before the diff does.
Key takeaways
- Run git diff --stat before you open a pull request, and split it when it passes 400 changed lines.
- Give each pull request one purpose; if its title needs the word and, open two.
- Put generated files such as a lock file in their own commit, so they do not hide the real change.
Worked example: one 830 line change cut into three
A feature adds a data change, new API endpoints and a screen. In one branch it is 830 changed lines, well past the band and close to Google's too large mark.
- Measure first.
git diff --stat origin/main...HEADprints a line count per file and a total. - Pick the order: the data change first, then the logic, then the screen. Each piece depends on the one before it.
- Cut the schema change into its own pull request: 210 lines.
- Build the API endpoints on top of it: 340 lines. Then the screen on top of that: 280 lines.
- Check each piece against the figure. All three sit under 400 lines, so each fits one sitting of an hour or so.
Result: Three readable pieces instead of one 830 line wall. Each one lands in the band where reviewers find most of the defects. Chained pull requests like these are a stack.
Questions readers ask
How many lines should a pull request be?
Aim for about 100 changed lines, and never more than 400 in one sitting. Google calls 100 lines usually reasonable and 1000 usually too large. GitHub itself sets no size limit, so these are guidelines from people who measured, not a rule the site enforces.
How do people review very large PRs?
They ask for a split first. Google's guidance is to ask the author to split the change into smaller ones that build on each other. When that is not possible, read it in sittings of 200 to 400 lines and stop at about an hour, then submit one review.
Do smaller pull requests merge faster?
Not reliably. A study across several languages found only a weak link between lines changed and how long a merge took. So promise what the evidence supports: small pull requests get better reading, not a sure faster merge.
Does code an AI assistant wrote get a size exemption?
No. An assistant writes faster than anyone reads, and the figure measures the reader. Keep one change per pull request, say what the assistant wrote and what you checked, and run the tests yourself before you ask for a review.
Sources: Small CLs (Google Engineering Practices); Best practices for peer code review (SmartBear, reporting the Cisco Systems study); About pull requests (GitHub Docs).
This figure is from GitHub Made Crystal Clear, chapter 4.
The chapter builds the idea step by step, with recipes you can follow, a Try it to check yourself, and every source.
Get the book
