| English | 中文 |
When an AI modifies many files at once, split the commits before pushing.
git add -p belongs in a clean or isolated task worktree. Inspect the Index and Working Tree first; if they contain staged, unstaged, or untracked content from another task, stop splitting in this worktree. Do not use reset or cleanup commands to move that content out of the way.
git status --porcelain
git diff --stat
git diff --cached
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 or used by collaborators:
git status --porcelain
git log --oneline --decorate -2
git reset --soft HEAD~1
git reset
git diff
git add -p
git diff --cached
After reset --soft, every hunk from the original commit is already in the Index. A direct git add -p does not unstage the hunk that was not selected. The argument-free git reset first restores the Index to the current HEAD while retaining all Working Tree edits, so partial staging can determine the next commit.
Both flows expect git status --porcelain to print nothing. If it prints anything, preserve the current state and continue in a clean task worktree. Exercise caution when rewriting history after pushing; confirm first if anyone else is continuing development based on that branch. The runnable Git command safety regression asserts the exact states.
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.