Keep each pull request to one self-contained change. Google's published engineering guidance treats about 100 lines as reasonable and 1,000 lines as usually too large. Smaller changes get reviewed sooner and more carefully, which matters for security because a reviewer can only catch what they actually read.
Why size changes review quality
A reviewer facing a 2,000 line diff does what any tired person does. They skim, look for obvious problems, and approve. A reviewer facing 80 lines reads every one of them.
Google's guidance on small changes says large changes tend to bury important points in long comment threads, and that fewer changes per review make bugs easier to spot. It also notes that small changes merge more easily and are simpler to roll back. The last point is a security point as much as a reliability one, because a bad change you can revert in minutes is a smaller incident.
What counts as small
The guidance is not really about line counts. It says the right size is one self-contained change that addresses a single thing, usually one part of a feature. File count matters too. A 200 line change in one file may be fine, while the same volume spread across 50 files is usually too large to hold in your head.
Some practical rules that follow from this:
- A pull request should have a one sentence description that does not contain the word "and".
- Tests for the logic go in the same pull request as the logic.
- Refactoring goes in its own pull request, separate from the feature or the fix.
- Mechanical changes, such as a rename produced by a trusted tool, can be large, but the reviewer still has to verify the tool did what it claimed.
Splitting a risky change
Authentication, authorization, input parsing and cryptography changes deserve the smallest slices you can manage. A useful order of work looks like this:
- Land the refactor that makes the change possible, with no behavior change.
- Add the new code path behind a switch that is off.
- Add tests that exercise both paths.
- Turn the new path on in a separate, tiny pull request that is easy to revert.
Each step is reviewable alone. The step that changes behavior is the smallest one, which is exactly where you want reviewer attention concentrated.
When a big pull request is unavoidable
It happens. A dependency major version bump or a generated file can produce thousands of lines. When it does, tell the reviewer where to look. Point to the hand written lines, list what was generated and how, and say what you checked yourself. Reviewers should feel free to ask for a split, and the Google guidance says reviewers may reject a change outright for being too large.
Measure it
Track median pull request size and time to first review for a month. If both are high, the cause is usually the same: work is being batched. Fix that first, because no checklist rescues a review nobody has time to do properly.
Safeguard can add a second reader to each pull request through policies and gates that run on every change, and its dependency scanning flags risky updates before they merge. You can try the free scan at gold.safeguard.sh/scan.
Quick check
Is 100 lines a hard limit?
No. Google's guidance calls it a reasonable size, not a rule. The real test is whether the change does one self-contained thing and can be understood in one sitting.
Should tests be a separate pull request?
No. Tests for new logic belong with that logic. Refactoring is the thing to separate.
Sources
Last reviewed: 19 October 2026.
