AI 辅助 Git 工作流

学完这篇你会掌握什么

• 让 AI 生成的改动在 Git 里可审查、可回退
• 写出经得起 AI 噪音、对人类仍然有用的提交信息
• 用 --force-with-lease 和 reflog 作为 AI 改写历史时的安全网
• 判断哪些 AI 产物该进 .gitignore、哪些绝不能提交

先想一个问题

你让 AI agent 重构一个特性分支。它动了 40 个文件、改写了两次提交历史、生成了一行提交信息，现在同事的分支没法干净合并了。改动本身可能很好——但你分不清哪些安全、哪些是 AI 幻觉、怎么回到已知良好的状态。问题不在 AI，而在于 AI 动得快，而 Git 的安全模型假设你会读每一个改动。

核心模型

Git 是一份你随时可以倒带的内容寻址历史。AI 工具是快速、乐观的编辑器，它跳过了人类本能会做的「读 diff」这一步。让两者安全协作的工作流很简单：让 AI 自由编辑，但让每一个 AI 改动在进入共享历史之前，都经过一个人工检查点。

也就是三个检查点：

1. 提交前审 diff —— git diff 和 git diff --staged 是必做项，不是可选。
2. 提交信息核对 —— 永远别盲信 AI 的信息；如果它只是复述 diff，就重写。
3. 强推守卫 —— AI 改写用 --force-with-lease，绝不用 --force。

一个安全的日常节奏

# 1. 从干净、最新的基线开始
git switch -c feature/ai-refactor
git fetch origin
git rebase origin/main

# 2. 让 AI 工具编辑（Copilot / Claude Code / Cursor / Aider）
# ... AI 改动 ...

# 3. 暂存前审查所有改动
git status
git diff

# 4. 按逻辑分块暂存——不要一坨提交
git add src/auth/
git diff --staged          # 再审一遍已暂存的
git commit                 # 写/核对信息

# 5. 如果 AI 改写了历史，先找回旧状态
git reflog                 # 找到改写前的 HEAD
git reset --hard HEAD@{1}  # 改写错了就撤销

写出 AI 伪造不了的提交信息

AI 工具默认会写 refactor: update auth module 这种信息——它复述了 diff，对评审者毫无信息量。一条有用的信息回答的是为什么：

auth: 把 token 校验从登录处理里拆出来

登录处理在一个 200 行函数里同时做 token 校验、登录、启动会话。
下一个改动里 API 中间件要复用 token 校验，所以这次先把它抽成
verifyToken()，行为不变。

验证：47 个 auth 测试全过。

如果 AI 的信息没说明动机，就重写。diff 已经展示了「改了什么」；信息存在的意义是记录「为什么」。

当 AI 改写历史时

Aider 和某些 agent 模式会改写提交（squash、重排、amend）。在本地、未推送的分支上这没问题。一旦分支被共享，改写就会制造混乱。规则：

• 只让 AI 改写尚未推送的提交。
• 如果必须改写共享分支，先沟通，并用 git push --force-with-lease——如果别人在这期间推过，它会中止。
• 改写前记下当前 SHA：git rev-parse HEAD，或者改写后查 git reflog。

--force-with-lease 是「我覆盖了同事工作」和「Git 拒绝并提示我先 pull」之间的区别。

哪些东西绝不进 Git（AI 产物）

AI 工具会生成一些必须排除在版本控制之外的文件：

# AI 工具产物
.aider*
.cursor/
.claude/
codeium/
*.prompt-cache

# 绝不提交密钥——AI 可能把它们漏进 diff
.env
.env.local
*.pem

AI 的风险比人类更高：AI 可能为了「修」某个东西读到密钥，然后粘到提交信息、测试夹具或注释里。每次提交前专门对着 git diff --staged 找一遍像 key 或 token 的内容。

常见误区

• 把 AI 一整段会话做成一个提交。 按关注点拆。git add -p 可以逐行暂存。
• 盲信 AI 提交信息。 如果它写「update files」或复述 diff，就重写。
• 用 --force 而不是 --force-with-lease。 在共享分支上这会悄悄毁掉别人的工作。
• 让 AI 直接 push。 让 push 保持为人工动作；AI 暂存和提交，人来审查和推送。
• 改写出错后跳过 git reflog。 改写前的状态几乎总还在。

健康 AI + Git 循环的前提

• 一个可以 rebase 上去的干净基线分支（git fetch && git rebase origin/main）。
• 一个排除 AI 工具状态和密钥的 .gitignore。
• 每次提交前读 git diff --staged 的习惯。
• push.default = simple 加上一条团队规则：只用 --force-with-lease。

给你的练习

1. 建一个临时分支，让 AI 工具做三个独立逻辑改动，分别用自己写的提交信息提交——练习拆分 AI 产出。
2. 让 AI 改写历史（rebase -i squash），然后用 git reflog 和 git reset --hard HEAD@{1} 撤销。
3. 用 git add -p 暂存改动，故意包含一行你不想要的，练习只把那一行取消暂存。

延伸阅读

• git-commit(1) — Official manual
• git-push(1) — force-with-lease
• Pro Git §5.2 — Contributing, Commit Guidelines
• 恢复：reflog 恢复
• 最佳实践：原子提交

延伸阅读

沿着同一主题继续深入：

• AI Coding Agent 下的 git worktree 模式
• API 版本变更工作流
• 使用 Cherry-pick 回移修复