祈灵工具箱

📜Conventional Commits 生成器 - 规范的 git 提交信息

团队刚开始用 Conventional Commits 时，最烦的是记不住有哪些类型、感叹号加在哪儿、BREAKING CHANGE 写在哪一段。这个生成器把规范拆成表单：选类型、填一句话说明、需要的话再写正文和破坏性变更，底下实时拼出提交信息，顺便给出可以直接粘到终端的 git commit 命令，还会提醒首行有没有超过 72 个字符。

免费 · 无需注册 · 浏览器本地处理最后更新：

正在加载工具...

如何使用提交信息生成

  1. 1选一个类型，页面会告诉你它对版本号的影响
  2. 2填影响范围和一句话说明（祈使句、现在时、不加句号）
  3. 3需要的话补正文、破坏性变更和关联 issue
  4. 4复制提交信息，或者直接复制整条 git commit 命令

常见问题

这些类型是谁定的？
Conventional Commits 规范本身只规定 feat 和 fix 两个类型，其余（docs、style、refactor、perf、test、build、ci、chore、revert）来自 Angular 的提交约定，现在是事实标准。团队可以增减，关键是一致。
类型怎么影响版本号？
配合 semantic-release 这类工具时：fix 让修订号 +1（0.1.0 → 0.1.1），feat 让次版本号 +1（0.1.0 → 0.2.0），带 ! 或 BREAKING CHANGE 的让主版本号 +1（1.2.0 → 2.0.0）。其它类型默认不发版。
首行为什么限制 50 或 72 个字符？
git log --oneline、GitHub 列表、邮件通知都按一行显示，超出会被截断或折行。50 是 Linus 当年的建议，72 是邮件正文的习惯宽度。这里按 72 提醒。
中文写提交信息可以吗？
可以，规范只约束类型和格式，说明部分写什么语言都行。注意字符数：中文一个字在终端里占两格，建议首行控制在 30 字以内。