A small pull request is easier to review carefully, and security problems hide in the lines nobody reads. Google's published engineering practices recommend one self-contained change per review, with roughly 100 lines usually reasonable and about 1,000 usually too large.
What the guidance says
Google's guide on small changes lists several benefits. Reviews are faster, since a reviewer can fit several five minute reviews into a day more easily than one half hour block. Reviews are more thorough, because large changes generate lots of back and forth and important points get missed. Changes are also easier to reason about, so there are fewer bugs.
The thorough point is the security one. A flaw in a 40 line change has nowhere to hide. The same flaw inside a 900 line diff competes with renames and formatting for attention.
What counts as small
The guide's principle is one self-contained change. In practice:
- It addresses one thing, often part of a feature.
- It includes its tests.
- The system keeps working after it merges.
- It is not so small that its meaning is unclear. A new API should ship with a usage.
Number of files counts as well. The guide notes 200 lines in one file may be fine, while the same spread over 50 files is usually too large. Deleting a whole file counts as about one line, and a change from a trusted automatic refactoring tool can be acceptable.
How to split in practice
- Separate refactors and formatting from behavior changes.
- Land dependency bumps on their own.
- Put security sensitive edits, such as permission checks, in their own pull request so the owner sees them undiluted.
- Use stacked branches for long features.
Separation also helps rollback. If the auth change is bundled with a UI change, reverting one reverts both.
The review side
Reviewers can ask authors to split a change. The guide says a reviewer may reject an overly large change outright. When splitting is not possible, it suggests giving design level feedback first so the author can proceed.
Do not count on reviewers to hold the line alone. Set a team norm and mention it in the contributing guide.
When big is unavoidable
Generated code, vendored files and lockfile updates are large by nature. Review the source of generation, not the output, and have a machine verify the output. Keep the human reviewed part separate.
Dependency updates deserve their own look, as covered in reading a lockfile diff.
A free scan of your dependencies is available at gold.safeguard.sh/scan.
A before and after
Imagine a feature that adds a new endpoint, renames a helper used in thirty files, and bumps two dependencies. As one change it is large, and the permission check on the endpoint is a few lines in the middle. Split it, and the rename becomes a mechanical change that a script can verify, the bumps are reviewed as bumps, and the endpoint pull request is short enough that the reviewer notices if the permission check is missing.
The work is the same. The attention is better spent.
Quick check
Is there a hard line limit?
No. Google gives rough guidance only, about 100 lines usually reasonable and about 1,000 usually too large, and says the reviewer's judgment decides.
Sources
Last reviewed: 19 October 2026.
