实用工具
输入
结果
结果会显示在这里。Conventional Commits（约定式提交）——feat(api): add streaming、fix: handle empty responses——是 semantic-release、release-please 和各种变更日志生成器用来决定下一个版本号、撰写发布说明的格式，而 commitlint 是大多数项目用来强制执行它的工具。粘贴一条或多条提交信息，这个检查器会应用 @commitlint/config-conventional 的规则：允许的类型、类型小写、描述不用句首大写且不以句号结尾、标题最多 100 个字符、正文和脚注前要空一行。每个问题都用 commitlint 自己的措辞和规则名报告，所以在这里改好的，就是提交钩子会报的。
它是怎么工作的
- 规则是根据 commitlint 源码重新实现的，并不运行 commitlint 本身，所以检查在页面里完成；规则集、严重级别和提示与 config-conventional 一致。
- 多条信息之间用只含 --- 的一行分隔。合并提交、revert、fixup!/squash! 提交和只有版本号的发布提交会跳过，与 commitlint 的默认行为相同。
- 破坏性变更——类型后的 !，或 BREAKING CHANGE: 脚注——会单独指出，因为发布工具会据此升级主版本号。
- 有一项是 commitlint 没有的：小写的 breaking change: 脚注会给出警告，因为规范要求这个标记全部大写，解析器会忽略其他写法。
你的数据去了哪里
哪也没去。本工具完全在你的浏览器里运行：你粘贴的文本由页面处理，不会传输到任何服务器，也不会写进任何日志。
本工具免费且无需登录，运行结果只存在于你当前的页面里，不会被保存到任何地方。
它要花多少
本工具完全免费，不需要登录，也不消耗积分。
常见问题
- 允许哪些类型？
- config-conventional 接受的十一种：build、chore、ci、docs、feat、fix、perf、refactor、revert、style 和 test。其他写法——首字母大写的 Fix、feature、update——都不符合 type-enum 规则。项目可以在自己的 commitlint 配置里扩充这个列表；这个检查器用的是默认配置。
- 为什么 "feat: Add login page" 会报错？
- config-conventional 禁止描述使用 sentence case、start case、pascal case 和 upper case，所以描述不能以大写字母开头，除非这个词本来就这么写。应写成 feat: add login page。专有名词可以加引号或反引号保留，大小写检查会忽略它们。
- 可以用中文写提交信息吗？
- 可以。大小写只存在于拉丁、希腊、西里尔等文字中，所以 更新安装说明 这样的描述能通过大小写规则。但类型仍必须是英文关键字：docs(readme): 更新安装说明 合规，文档: 更新安装说明 不合规。
- 标题上限为什么是 100 而不是 72？
- 100 是 config-conventional 的默认值。很多团队更喜欢 72，这样在 git log --oneline 和 GitHub 的提交列表里标题不会被截断；把标题最大长度设为 72 即可按这个标准检查。
背后的开源项目
本工具是独立实现，并未打包第三方库。conventional-changelog/commitlint（MIT）在代码层面做的是同一件事——如果你需要在自己的程序里实现它，从那里开始，而不是调用一个网页。
conventional-changelog/commitlint也常被称作
- commit message 检查
- conventional commits 规范
- commitlint 在线
- git 提交信息规范
- 约定式提交
- 提交信息格式