| English | 中文 |
When an AI modifies many files at once, split the commits before pushing.
git diff --stat
git add -p
git commit -m "test(module): cover edge case"
git add -p
git commit -m "fix(module): handle edge case"
If already committed as one large commit, but not yet pushed:
git reset --soft HEAD~1
git add -p
Exercise caution when rewriting history after pushing; confirm first if anyone else is continuing development based on that branch.
Prioritize splitting into these types:
Do not put “bug fix + large refactor + formatting + dependency upgrade” in the same commit.
Meta Sapling’s public practice uses a stack of commits as an important workflow, suitable for splitting large features into multiple continuous small changes.
After an AI generates a large diff, you can also organize it with this mindset:
commit 1: add failing test
commit 2: change implementation
commit 3: update docs
commit 4: remove obsolete helper
Each commit should be independently explainable, and the sequence should be clear.
When a large diff exceeds the review capacity of a single PR, it can be further split into stacked PRs. Commit splitting solves the issue of clear history within a PR, while stacked PRs solve the issues of multi-person review and layered merging.
Both Google’s small CLs and Meta Sapling show that making changes smaller first leads to more accurate reviews. When AI modifies code, the core value of splitting is cutting risks back to a judgeable range. For case comparisons, see Enterprise Git Workflow Stack Decision Map.