AI 让写代码变便宜，但让验证代码变贵。
Git 在 AI 编程时代的新价值，是把 AI 生成的大块改动，拆回人类能理解、能审查、能回滚的小块变更。
想把这些日常操作放进同一个 timeout 修复案例，从任务契约一路看到候选 SHA、集成、制品和恢复，可以先读一次工程变更，从任务契约走到恢复。本文保持为日常分支、worktree、diff 和提交操作的速查。
AI 改代码通常有几个特点：
所以 AI 编程后的 Git 工作流，重点是让变更重新变小、变清楚、可验证，不能只看生成和提交速度。
不同 AI 工具接入 Git 的方式不同，但目标一致：把 AI 修改限制在可审查、可回滚的小范围内。Codex 更强调远程环境和 sandbox，Claude Code 强调 worktree 隔离，Copilot Cloud Agent 更贴近 Issue 到 PR，Aider 则把本地 Git 提交和撤销作为核心体验。详细对比见 AI 编程工具的 Git 集成实践。
一个 commit 只表达一个完整意图。
如果 AI 一次改了 20 个文件，先审 diff，再拆成多个 commit。
每个任务一个分支。
AI 探索性改动不要直接落在 main、master、develop 或长期维护分支上。
提交前先看：
git status
git diff
git diff --stat
如果你无法在几分钟内讲清这次 diff 为什么存在，就先不要提交。
每次 AI 改动都要留下验证方式：
AI 可以生成代码、解释 diff、做第一轮 Review，但最终合入决定必须由人类负责。
每个 PR 都要能回答：
git revert<integration-branch> 表示团队约定的实际集成分支，例如 main、master 或 develop。先从仓库规则和 PR 目标确认它的名称，不能把 main 当作所有仓库的默认值。
下面的流程要求当前工作区没有待处理编辑。git status --porcelain 只要有输出，就停止；保留现场，或在独立的干净 worktree 继续。不要在这个工作区执行 switch、pull、reset、restore 或 clean 来清掉别人的编辑。
git status --porcelain
git branch --show-current
git switch <integration-branch>
git pull --rebase origin <integration-branch>
git switch -c feat/ai-assisted-short-task
适合并行让多个 AI 工具处理不同任务：
git worktree add ../my-project-task-a -b feat/task-a
git worktree add ../my-project-task-b -b feat/task-b
官方文档见 git worktree。
给 AI 的任务要足够具体：
只修改订单校验逻辑，不调整接口签名，不改动无关格式化。
完成后列出改动文件、行为变化、验证方式和潜在风险。
git status
git diff --stat
git diff
重点看：
用交互式暂存拆分变更。它适合干净或隔离的任务工作区，先检查 git diff --cached，确认 Index 里只有本次意图：
git add -p
git commit -m "fix(auth): handle expired token"
如果已经提交成一个大 commit，并且该 commit 尚未 push、未被协作者使用，可以重新拆分。先确认当前分支、最后一个 commit 和干净基线：
git status --porcelain
git log --oneline --decorate -2
git reset --soft HEAD~1
git reset
git diff
git add -p
git diff --cached
reset --soft 会把原 commit 的全部改动留在 Index。紧接着运行 git add -p 没有可选择的未暂存 hunk，下一次普通 commit 会带上全部改动。第二个无参数 git reset 把 Index 还原到当前 HEAD，Working Tree 保持原样，随后 git add -p 才能只选本次 commit 的 hunk。
git status --porcelain 有任何输出时，不要执行这两个 reset。已有 staged、unstaged 或 untracked 内容需要保留时，改用干净的任务 worktree。可运行的反例和修正流程见 Git 命令安全回归。
如果 AI 生成的是一个跨层大功能，可以考虑拆成一组有依赖关系的小 PR，让测试、实现、清理、文档分层进入 Review。详细见 Stacked PR for AI-Generated Changes。
根据项目类型选择最小必要验证：
npm test
mvn test
go test ./...
pytest
没有测试时，也要写清本地验证路径。
可以让 AI 按固定清单检查：
请基于当前 git diff 做 Review。
重点检查：行为范围、错误处理、兼容性、测试有效性、安全风险、无关改动。
不要泛泛总结，只列出具体风险和文件位置。
PR 描述至少包含：
可以直接使用 PR Template。
AI 代码尤其要依赖 CI 做最低质量验收。
如果团队使用 GitHub，建议配合分支保护、必需状态检查、Review 要求，见 GitHub branch protection docs。
docs: explain the behavior
test: cover the failing case
fix: change the implementation
refactor: simplify local helper
fix all ai changes
update files
misc
wip
一个 commit 应该能独立回答：
feat/short-description
fix/bug-description
docs/topic-name
ai/experiment-short-description
ai/task-a
ai/task-b
ai/review-task-a
多 Agent 最好配合 git worktree，避免多个工具在同一个工作区抢文件。
完整模板见 AI Code Review Checklist。
跨层或跨 owner 的大变更，优先拆成 stacked PR，避免一个 PR 同时承担需求解释、代码理解、测试验证和风险判断。
风险：diff 太大，Review 失效。
建议：先让 AI 输出计划，再按小任务逐步改。
风险：无关文件、调试代码、配置改动混入。
建议：永远先 git diff。
风险：行为变化和结构变化混在一起。
建议：拆成多个 commit 或多个 PR。
风险：别人基于旧提交做的工作丢失。
建议：公共分支优先用新 commit 修正，确实需要重写历史时先确认协作者状态。
# <integration-branch> 由团队的仓库规则确定，例如 main、master 或 develop
git status --porcelain
# 预期没有输出；有输出时停止并保留现场
git switch <integration-branch>
git pull --rebase origin <integration-branch>
git switch -c fix/order-timeout-validation
# AI modifies files
git status
git diff --stat
git diff
git add -p
git commit -m "test(order): cover timeout validation"
git add -p
git commit -m "fix(order): reject expired timeout config"
mvn test -pl order-service -Dtest=OrderTimeoutValidatorTest
git push -u origin fix/order-timeout-validation
PR 中写清：
What changed:
Add validation for expired timeout config.
How tested:
mvn test -pl order-service -Dtest=OrderTimeoutValidatorTest
Risk:
Low. Only affects invalid timeout config path.
Rollback:
Revert this PR.