| English | 中文 |
The goal of a PR is to make a change understandable, reviewable, testable, and reversible.
If a reviewer cannot review it within a reasonable time, the PR is too large.
It can be split into:
The value of a small PR lies mainly in being easier to understand, roll back, and stack for review; avoid making blanket claims that “small PRs always merge faster.”
Research has found no stable correlation between change size and merge time. Teams should still encourage small PRs, but the reasoning should focus on reviewability, verifiability, and reversibility; see Empirical Git Workflow Research Notes.
Public practices like Google Code Review and Meta Sapling point to the same conclusion: the core value of small changes is lowering comprehension barriers and risk-isolation costs. When AI generates large diffs, they should also be broken down into smaller, human-reviewable units first; see Tech Giant Engineering Practice Decision Map.
When a feature is inherently large, it can be broken down into a series of dependent small PRs:
PR 1: data model
PR 2: service logic
PR 3: API
PR 4: tests and docs
This approach is suitable for large features, AI-generated large diffs, and cross-module refactoring.
Things to Note:
Use the Pull Request Template directly.
After AI generates code, the PR description should not merely say “AI generated.”
At a minimum, clarify: