Phase 5 / Ep 28: 自动化的 Conventional Commits

⏱ 预计阅读 3 分钟 更新于 2026/4/13

今天你的功能写完了，如果不给 Agent 下规范化限制指令，它要是想代你提交代码了，可能就会在提交历史线上非常敷衍地留下一句：“git commit -m 'fixed things'”。

在未来你要根据历史溯源或者做 release 小版本回滚的时，这就等于是一个天书噩梦！ 在系统根目录的法典中，我们要加上一条专属管辖版本线的规则工作流 .agents/workflows/git-push.md：

1. 版本之神的心法指令

# 强控制的 Git 提交准入规范

如果触发自动或代签发布动作：
1. **严格 Conventional Commits 协议约束**：任何的变动必须是 `feat: `（特征）、`fix: `（修复）、`chore: `（杂项构建任务）、`refactor: ` 等打头。
2. 你必须结合今天在 `progress.md` 里的长难信息。生成一段带有为什么采取这方案（why），而不单是改了什么的 commit 的超详细描述。
3. 因为你修改代码很快，强制每次使用 `git status` 看一下究竟动到了哪几处文件再发起包裹整合提交链，不准出现把无关的文件错夹带推送的事！

现在，当大模型接到你的指令：“帮我收拾并推送到远端！” 它生成到 GitHub 上的记录将会极其优雅并带着条理列项。一个拥有极佳开发者素养的提交记录诞生，而这个代码史上的小神仙操作没有耗费你一分多余的时间精力。