起点
用 AI 编码 Agent 时间久了，出现一个现象：我越来越信任它写代码的正确性，但越来越不信任它对 Git 的操作。
几种典型事故：
- Agent 在
develop保护分支上直接 commit，理由是”我就改一行” git add -A把所有 untracked 临时文件、测试脚本、日志文件一起提交了- 在已推送的分支上执行 rebase，理由是”整理历史”
- merge conflict 时不报告、不暂停，直接按自己的理解解决掉
- 不同分支的修改混在同一个 commit 里，commit message 还写 “WIP: 第一阶段”
每次事故的后果都不致命——毕竟可以 revert、可以 force push（在允许的情况下）。但频繁的”惊吓”会降低对 Agent 的信任。我开始思考：能不能把 Git 操作规则写下来，让 Agent 每次操作 Git 时都先读一遍？
不是”教”Agent 用 Git，是”约束”它的操作边界
Agent 不需要从头学 Git——它的 Git 命令水平比大多数人类都强。问题在于它缺少”操作前的判断”：什么能做什么不能做，什么时候该停下来问。
所以这套规则的设计目标不是”教学文档”，而是行为约束文档。类似于 API 的 rate limiting——不是说你的请求不对，是”你不能在这个条件下发送这个请求”。
从三段式前置检查开始
所有写操作（commit / rebase / merge / push）之前，强制执行一个三段式检查：
[1] git status --short
[2] git log --oneline -3
[3] git fetch && git status -b- 第一步确认工作区是干净的。
- 第二步确认当前在正确的分支上。
- 第三步确认本地和远程的同步状态。
任何一步不符合预期就停止，报告状态，等待指示。不给 Agent 留下”我看情况自己决定”的空间。
分支权限表：用表格代替文字
文字描述”禁止在 develop 上提交”很容易被 Agent 理解为”尽量不要”而非”绝对禁止”。表格的呈现方式比文字更有约束力：
| Branch | 直接提交 | Rebase | 推送到远程 | 合入 develop |
|---|---|---|---|---|
| master / main | 禁止 | 禁止 | 禁止 | — |
| develop | 禁止 | 禁止 | 禁止 | — |
| feature/* | 允许 | 仅未推送时 | 仅明确指令 | merge |
| fix/* | 允许 | 仅未推送时 | 仅明确指令 | merge |
用”禁止”而不是”不建议”。Agent 对这两个词的遵从度差异极大。
Rebase 的”已推送”边界
这是最关键的规则：已推送的分支禁止 rebase。
实现上不需要 Agent 自己判断——给它一条判断命令：
git branch -r --list '<branch-name>'无输出说明未推送 → rebase 允许。有输出说明已推送 → rebase 禁止。
这条规则避免了最危险的一类 Git 事故：rebase 已推送分支导致协作历史混乱。
提交约束：不只关于命令，还关于消息
暂存：禁用 git add -A
git add -A 是 Agent 的默认倾向——因为它”最简单”。但这个习惯会混入 untracked 临时文件、日志、测试脚本。规则限定为：
git add -u（仅已跟踪文件）git add <path>（明确指定路径）
对 Agent 来说多了一步操作，换来的是提交内容的可控。
GPG 签名：不允许绕过
依赖 commit.gpgsign=true 全局配置。如果 GPG 签名失败，规则明确要求”立即终止，不绕过，向用户报告”。
不是因为签名本身有多重要，而是”绕过安全措施”这个行为的开口不能开。
提交消息：禁止的四种内容
| 禁止 | 原因 |
|---|---|
| 版本号（v2.0、1.3.2） | rebase 或 tag 变化后变成垃圾信息 |
| 过程化标记（WIP、—temp） | 合入后无意义 |
| 外部引用（issue 号、PR 号） | 脱离当前仓库后不可追溯 |
| 元操作描述（“拆分”、“移动”） | rebase 过程本身不是提交内容 |
每条禁止项后面都跟了”为什么”，因为 Agent 对”被禁止”有天然的追问倾向——给原因能大幅减少它试图绕过规则的尝试。
推送禁令：默认禁止，单次生效
这是 Agent 行为约束中最重要的一条：
- 默认禁止推送任何分支
- 只有用户明确说”推送”或”push”并指向具体分支时才执行
- 单次生效——下次需要新的明确指令
- develop / master / main 永远不推送
- 禁止强制推送（—force / —force-with-lease）
“提交代码”、“合并到 develop”、“commit”都不算推送指令。这个区分对 Agent 很重要——它会天然认为”提交=推送”。
边界场景：不是写规则，是写”什么时候停下来”
规则中单列了一个”边界场景”表，告诉 Agent 什么情况下不应该继续操作：
| 场景 | 处理方式 |
|---|---|
| 提交时不在 feature/fix 分支 | 停止，提示先切换或创建分支 |
| rebase/merge 发生冲突 | 停止，报告冲突文件和上下文 |
| 工作区有未提交变更即要求切换分支 | 停止，提示先提交或 stash |
| 已推送分支上执行 rebase | 停止，拒绝 |
| 将任何分支合并到 feature | 停止，拒绝 |
每一个”停止”都明确写了要报告什么信息——不给 Agent 留省略空间。
意外情况：保护现场
还有一个专门的约束：遇到脏工作区、冲突、分支错误时：
- 不自动撤销
- 不自动 stash
- 不丢弃未提交的变更
- 立即停止，报告当前状态和上下文，等待用户指示
Agent 的”帮助倾向”在这种场景下反而是危险的——它可能会在用户不知情的情况下 stash 了重要的未提交代码。
设计原则
回看这套规则，三个原则贯穿始终：
1. 用表格代替说明。 Agent 对”禁止/允许”二元表格的遵从度远高于自然语言描述。表格提供了明确性，明确性降低了 Agent 自行解释的空间。
2. 每个禁止项都必须给”为什么”。 不给理由的规则会被 Agent 视为”可协商”。给了理由后，Agent 更倾向于遵守而非挑战。
3. 告诉它什么时候停，比告诉它怎么走更重要。 Agent 的 Git 技能足够强，不需要”怎么 rebase”的教程。它需要的是”什么情况下你不应该 rebase”的约束。
小结
这套规则不是什么原创发明——大部分来自 Git 社区共识和团队协作规范。唯一做的工作是把这些共识从”人类之间的默契”翻译成了”人类对 Agent 的约束”。
翻译过程让我意识到：人类开发者之间的 git 规范大量依赖”上下文理解”和”心照不宣”——“大家都知道不要 force push”、“大家都能读懂冲突”。而 Agent 需要的恰恰相反：它需要每个边界被显式标注、每个禁止被给出理由、每个异常被预设响应。
如果你也在让 AI 操作 Git，可以试试给它的 system prompt 里加一段类似的行为约束。比事后修 force push 的代价小得多。