你几乎肯定以前见过传统提交规范。它可能在你使用的开源项目的变更日志中出现过。它可能是你贡献的开源项目强制的提交格式。很多人对它推崇备至。我却对它嗤之以鼻。尽管许多流行的开源项目都在使用传统提交规范，但它实际上是一个糟糕的标准，鼓励关注错误的事物，并未能兑现其承诺。 关注的失败 传统提交规范承诺为提交消息添加语义意义，以帮助开发人员和最终用户理解提交中所做的更改。然而，传统提交规范未能在这方面做到令人满意。为了证明这一点，让我们看看一个传统提交的结构。根据传统提交规范的网站，提交信息的格式应如下所示： <type>[可选范围]: <描述> [可选主体] [可选脚注] 提交的主题行包含一个<type>（类似于fix、feat、chore、docs或refactor）来描述更改的类型。在此之后，有一个可选的范围，然后是描述。这个格式有一个主要缺陷：类型优先于范围。这个顺序完全颠倒了。 范围 > 类型 更改的范围（更改的主题）是提交中最重要的部分。为了说明这一点，让我们考虑以下各方为什么更关心更改的范围而不是更改的类型： 贡献者：当你是一个项目的贡献者时，你通常需要查看提交日志，以识别与代码库中某个区域相关的更改。这有很多原因，包括：想要了解自上次贡献以来发生了什么；试图理解项目的整体趋势；寻找在拉取或变基时可能与正在进行的工作冲突的提交。当你查看提交日志时，你关注的是哪些区域被触及。你并不关心更改的类型，而更关心更改的范围。 调试者：在调查错误时，你通常希望浏览提交日志，以查看可能影响与错误表现相关的组件的更改。同样，范围是最重要的信息。更改的类型完全无用，因为在任何类型的更改中都可能引入错误。（我相信大家都有过写出的错误修复导致了另一个错误的经历。） 事件响应者：当生产环境停机时，扫描在故障发生时所做的更改的提交日志是一种有效识别可能导致问题的区域的方法。范围再次是此时你可以拥有的最重要的信息。例如，如果你在入站API错误激增的尖峰时看到与身份验证范围相关的提交，它可能就是问题的罪魁祸首。再一次，类型无关紧要，因为错误可能由任何更改引入。那么，传统提交规范究竟做了什么呢？它将范围的优先级降低到可选的地步！为什么范围会是可选的？没有范围的提交就像没有主语的句子！然后，雪上加霜的是，传统提交规范将类型提升到了提交消息的前面。传统提交规范完全错误地认识了范围和类型的优先顺序。 类型是冗余和限制性的 你可能会想，“所以它可能是反的，但提交类型至少仍然重要，对吧？”对此我说“不”。提交的描述几乎总是应该告诉你更改的类型！考虑这个提交消息作为例子：fix(compiler)：防止命名空间SVG <style>元素被剥离。即使你只有描述，显然这是一个错误修复！提交主题行的空间已经十分紧张，把字符浪费在类型上毫无帮助！但往往更糟糕的是，它往往是限制性的。以这个提交消息为例：refactor(core)：更新webmcp支持，以使用document.modelContext。这个提交更新了核心组件中的webmcp功能，以支持document.modelContext和navigator.modelContext，那么这是一个错误修复、重构还是新特性？我认为这三者都有！但再一次，真正重要的只是这是对核心/webmcp组件的一次更改。传统提交规范根本关注错误的内容（提交类型），贬低了范围（人们真正关心的内容）。 破碎的承诺 所以我们已经确定传统提交规范的格式糟糕，但它一定提供了一些好处。让我们阅读“为什么使用传统提交规范”部分，看看是否有任何理由讲得通。自动生成CHANGELOG。这是传统提交规范最大的承诺：你可以运行像git-cliff或conventional-changelog这样的工具来生成变更日志。