【声明】本博客所有内容均为个人业余时间创作，所述技术案例均来自公开开源项目（如Github，Apache基金会），不涉及任何企业机密或未公开技术，如有侵权请联系删除
背景
上篇 blog
【Agent】【OpenCode】bash 工具提示词（git 提交规则）
分析了如何发送多条命令，四条规则：能并行的就并行，有先后顺序的用 &&，不在乎失败的命令用 ;，禁止用换行符，然后是切换目录的规矩，这点之前 blog 分析过，然后是提交规则，这些提交规则用来规范 AI 帮助用户使用 Git 命令提交代码时的行为，防止 AI 自作主张改动 Git 仓库，或者执行一些可能导致代码丢失的危险操作，具体规则包括：明确命令才动手，严禁主动提交，不动配置文件，不执行毁灭性命令（除非用户明确要求），不绕过安全检查（除非用户明确要求），接着重点提到了使用 --amend 选项的注意事项，git commit --amend 可以用来修改最近一次的提交信息，但必须同时满足如下所有条件才能使用，否则一律创建新的提交：用户明确要求 amend，或者是提交成功后 Git 钩子自动修改了文件，需要补录，而且要 amend 的提交必须是 AI 在这次对话中刚刚创建的，并且这个提交还没有被推送到远程服务器，下面继续分析
OpenCode
上篇 blog 提到了两个关键场景禁止使用 --amend
这两个场景都是为了保护用户的代码仓库不被意外修改，在 Git 里，--amend 修改历史记录是件很敏感的事情，尤其在多人合作的项目中，如果操作不当，很容易导致代码冲突甚至丢失，下面来详细分析下这背后的逻辑
首先是失败处理 ：提交失败，或者被钩子拒绝后，不能用 --amend，这主要是为了保留失败现场，方便排查问题，有几个点
- 保留历史痕迹 ：如果一次提交失败了，比如被 pre-commit 钩子拦截，或者因为代码冲突没提交进去，说明这次操作本身是有问题的，比如需要先解决冲突，或者更新代码，如果 AI 此时强行用
--amend去修补这个提交，就等于把失败的尝试和修复后的结果混在了一起，抹去了中间的过程 - 清晰的排查链路：让 AI 修复问题后，创建一个全新的提交，用户的 Git 历史记录里就会清晰地留下痕迹，比如【第一次尝试（失败了/被拒绝）】->【第二次尝试（修复了问题，提交成功）】，这样万一后续代码出了 bug，用户回看历史记录时，可以清楚知道哪次修改是为了解决什么问题的
接下来是已推送处理 ：代码推送到远程后，不能用 amend，这是 Git 协作中很重要的一条规则，永远不能修改已经推送到远程的公共历史，有几个点
amend的本质是篡改历史 ：当amend一个已经推送过的提交时，Git 实际上是把原来的那个提交先删掉，然后用同样的内容，或修改后的内容生成一个全新的，哈希值（Commit Hash）完全不同的提交来顶替- 引发别人的灾难 ：假设用户和别人都在同一个分支上开发，用户推送了提交 A，而队友拉取了提交 A，然后用户本地
amend了提交 A（变成了提交 Aa），并强行推送到了远程，此时，远程仓库里的 A 变成了 Aa，但别人本地还保留着旧的提交 A，当别人再次拉取代码时，Git 会发现远程的提交 Aa 和本地的提交 A 长得像，但哈希值完全不一样，此时 Git 会认为这是两份完全不同的代码，就会产生极其复杂的代码冲突 - 强制推送的风险 ：要覆盖远程的旧提交，就必须使用
git push --force进行强推，这在团队协作中是非常危险的操作，因为该操作会直接覆盖掉别人可能已经基于旧提交开发好的功能，导致别人的工作成果丢失
所以基于以上两点，提示词在上述两个场景，对 amend 做了限制（禁止使用）
最后这里再次强调了，没有用户的明确要求，禁止擅自提交改动，否则会让用户觉得 AI 过于主动，引发风险
OK，本篇先到这里，如有疑问，欢迎评论区留言讨论，祝各位功力大涨，技术更上一层楼！！！更多内容见下篇 blog