| English | 中文 |
This article uses a simulated scenario to illustrate how humans use Git to reorganize changes into reviewable, verifiable, and rollback-ready engineering units after AI has modified the code.
You asked the AI to fix a problem:
When the order timeout configuration is empty, the system should use the default timeout and should not throw an exception directly.
After the AI finishes, the workspace looks like this:
git status --short
M src/order/timeout.ts
M src/order/validator.ts
M src/order/index.ts
M test/order/timeout.test.ts
M package-lock.json
M README.md
?? debug-output.log
At this point, do not directly git add ..
git diff --stat
Focus on three things:
In this example, the task is to fix the order timeout configuration, but the following appeared:
src/order/index.tspackage-lock.jsonREADME.mddebug-output.logThese all need to be confirmed for relevance first.
A status listing says that a path changed, not who owns it. In this scenario, package-lock.json, README.md, and debug-output.log may have come from the AI, or they may be edits, debugging evidence, or pending work owned by a person or another agent.
Record the staged and unstaged scope first:
git status --short
git diff --cached --name-only
git diff --name-only
Classify each path as a complete path for this task, an edit owned by someone else, or unconfirmed. Leave unconfirmed paths and paths owned by someone else unchanged. A path-limited commit below leaves them in place when the current commit does not need them.
Discarding content requires path ownership, the expected baseline, and owner authorization. For example, only run this after the owner explicitly confirms that debug-output.log is a disposable AI temporary file:
rm -- debug-output.log
Only run this after the owner confirms that both tracked paths were wholly generated by the AI and should return to HEAD:
git restore --source=HEAD --staged --worktree -- package-lock.json README.md
The latter command overwrites both the Index and Working Tree for its named paths. Stop rather than run restore, git clean, or a broad reset if a named path contains a user hunk, existing staged content, or an uncertain source.
Look at the tests first:
git diff -- test/order/timeout.test.ts
Assume manual review confirms that the test file is a complete tracked path for this task and has no pre-existing staged hunk. Commit its Working Tree version by naming only that path:
git diff -- test/order/timeout.test.ts
git diff --cached -- test/order/timeout.test.ts
git commit --only -m "test(order): cover empty timeout config" -- test/order/timeout.test.ts
Then look at the implementation:
git diff -- src/order/timeout.ts src/order/validator.ts
Confirm that the implementation only changed the default value handling and did not incidentally change error codes, interface signatures, or log formats.
The two implementation paths must also be complete tracked paths for this task, with no pre-existing hunk in git diff --cached:
git diff -- src/order/timeout.ts src/order/validator.ts
git diff --cached -- src/order/timeout.ts src/order/validator.ts
git commit --only -m "fix(order): fallback to default timeout config" -- src/order/timeout.ts src/order/validator.ts
git commit --only reads the complete Working Tree version of each named path and preserves staged, unstaged, and untracked content in other paths. It is not for committing only already-staged hunks from the same file, and it cannot distinguish multiple intents inside that path. For such a file, move to a clean or isolated task worktree, then use git add -p and an ordinary git commit. The runnable Git command safety regression covers both boundaries.
This results in two final commits:
test(order): cover empty timeout config
fix(order): fallback to default timeout config
You can hand the current diff or commit range to an AI for review:
Please review the changes in the current branch relative to the team's agreed integration branch.
List only specific risks, do not provide vague summaries.
Key checks:
1. Whether behavioral boundaries have been expanded
2. Whether error handling has become weaker
3. Whether default values affect compatibility
4. Whether tests cover real business scenarios
5. Whether irrelevant changes are mixed in
If the AI’s output lacks file paths and specific risks, and only says “looks good,” this review round has very low value; push back with more specific prompts.
A human reviewer should at least confirm:
When production configurations are involved, static code can only describe default behavior. The final production values still need to be confirmed in conjunction with configuration centers, environment variables, or deployment parameters.
Run only the most relevant validations for this change:
npm test -- test/order/timeout.test.ts
If the project has lint or type checking, include those as well:
npm run lint
npm run typecheck
The PR should clearly state the actual commands executed and their results.
Recommended PR description:
## What changed
- Add test coverage for empty timeout config
- Fallback to default timeout config when config is empty
## Why
Empty timeout config should not break order validation.
## How tested
- npm test -- test/order/timeout.test.ts
- npm run lint
## Risk
Low. The change only affects empty timeout config fallback.
## Rollback plan
Revert this PR.
If the AI changed cross-layer capabilities at once—for example, model, service, API, UI, and documentation all changed—a single PR is still hard to review.
In this case, it can be split into stacked PRs:
PR 1: add tests for timeout fallback
PR 2: implement timeout fallback
PR 3: update API response note
PR 4: update docs
See Stacked PR for AI-Generated Changes for details.
Risk: Irrelevant files, debug logs, and dependency changes will be mixed in.
Suggestion: Always look at git diff --stat first.
Risk: AI might write tests that only verify the current implementation.
Suggestion: Confirm whether tests cover business boundaries and try to confirm they fail before the fix.
Risk: Reviewers cannot determine where the risk comes from.
Suggestion: Fix behavior first, then perform refactoring separately.