dev.to 第 21 篇草稿：/commit 单篇
标题：提交信息别再写 update 了：/commit 的 5 条硬规则
说明：本文是整理，不是新实测。内容来自完整版 commands/commit.md 原文。/commit 是 Lite 版 3 条命令之一（Lite 版免费就有 /review、/commit、/test），完整版同款命令，另含其余 7 条命令与三套模板、速查表。本文只讲 /commit 这一条，不编造新实测。注：GitHub 上有两个描述均为“Lite 版 3 分钟上手：装好 + 第一次用 /commit”的 Gist，未能核实哪一个是命令原文，故文末不挂 Gist 链接，只放 Lite 仓与爱发电商品页两链接。
1. 只读 diff 生成信息，不替你 add、不自动提交
/commit 的输入是暂存区：先看 git diff --cached（无暂存时看 git diff），理解这次改了什么，再生成信息。它不替用户执行 add，只读 diff 生成信息；生成的完整信息展示给用户，问“直接用这条提交吗？”——提交动作永远由用户确认。
想让它自动提交，别用这个命令；暂存区是空的，先 add 再来。
2. 一次提交只取一个主类型，混了不相关的改动先拆
类型只有七个：feat（新功能）/ fix（修 bug）/ docs / refactor / test / chore / perf。一次提交只取一个主类型；如果 diff 里混了两种不相关的改动，先提醒“建议拆成两次提交”，给出拆分建议。
相关与否看“是否为同一目的服务”：命令原文给的例子是，选型文档是本次 commands 的依据 → 相关，可合；README 顺手改动混进功能提交 → 不相关，建议拆。一次提交包含重构 + 功能 + 修 bug 三件套，先拆，拆不动再接受“这次信息会比较长”。
3. 主题用祈使句，≤50 字符，句首小写，无句号
格式：类型前缀 + 祈使句主题，如 fix: 订单缺失 level 时不再抛 KeyError。中文主题允许，但中英混排时保持术语一致。
反面就是团队里最常见的那几种：update、fix bug、一句写不完的长句。主题的作用是让看日志的人一眼知道这次改了什么类型、改了什么事，不是写小作文的地方。
4. 正文只写“为什么”，不复述 diff 里已有的“改了什么”
正文只在需要时加，上限是主题 + 三行正文。只解释“为什么”这样改，bug 修复注明根因一句话。命令原文的示例：
fix: 订单缺失 level 时给默认值 normal
根因：batch_settle 直接取 o["level"]，上游缺失字段时崩溃。
改用 o.get("level", "normal") 兼容历史数据。
“改了什么” diff 里已有，再抄一遍是浪费；“为什么” diff 里没有，写下来才是三个月后的人需要的。
5. 输入输出示例：两处修改先判相关，再决定合还是拆
命令原文的输入示例：暂存区是 orders.py 的两处修改（文件关闭改 with、level 取值加默认值），输出是 fix: 修复文件句柄泄漏与缺失 level 时的 KeyError + 正文说明两处根因；若 diff 还混入 README 改动 → 提醒拆分。
这条规则的实用价值在评审时最明显：一条提交只做一件事，/review 才能按提交逐条看；提交信息写清楚了，三个月后查日志也不用再翻 diff 猜意图。
不用 /commit 的场景
- 暂存区是空的：先 add 再来。
- 想让它自动提交：这个命令永远只生成信息、不执行提交。
- 提交信息想写小作文：主题 + 三行正文是上限，写多了没人看。
- 一次提交包含重构 + 功能 + 修 bug 三件套：先拆，拆不动再接受“这次信息会比较长”。
价格与链接
完整版中文 AI 编程 CLI 工作流包：早鸟 ¥9.90（限前 100 份），正式 ¥19.90。/commit 本身在 Lite 版免费版中已有，完整版是 10 条命令全量。
Top comments (0)