别再使用常规提交规范了
你很可能之前就遇到过 常规提交规范。它可能曾在你使用过的开源项目的更新日志中冒出来，也可能是你贡献过的开源项目强制要求的提交格式。很多人对它深信不疑，但作者却对此嗤之以鼻。尽管众多知名开源项目都在使用这一规范，但常规提交规范实际上是一个糟糕的标准，它 让人关注无关紧要的东西，且无法兑现它的承诺 。
关注点的失败
常规提交规范承诺为提交信息添加语义，以帮助开发者和最终用户理解提交中所做的更改。然而，它在这方面的表现却一塌糊涂。提交信息应按以下格式编写：<类型>[可选作用域]: <描述> [可选正文] [可选脚注]。这种格式有一个重大缺陷： 类型的优先级高于作用域 。这完全是本末倒置。
作用域比类型更重要
更改的 _作用域_（即更改的主题）是提交中最重要的部分。贡献者、调试人员、事故响应人员更关心更改的作用域而非类型。常规提交规范将作用域的优先级降得很低，甚至使其成为 _可选_ 的，还将 _类型_ 放在提交信息的最前面，完全搞错了作用域和类型的优先级。
类型冗余且具有局限性
提交的描述几乎总能告诉你更改的类型，把字符浪费在类型上毫无帮助，而且它往往不仅无用，还具有局限性。常规提交规范从根本上关注了错误的东西（提交类型），而贬低了作用域（这才是人们真正关心的）。
无法兑现的承诺
我们来看看常规提交规范所谓的好处是否合理。
自动生成更新日志
这是常规提交规范最大的承诺，但更新日志的受众与提交日志的受众完全不同，任何将它们结合起来的尝试都会导致效果不佳。
自动确定语义版本号的升级（基于提交的类型）
软件工程的实际情况往往会严重影响准确完成这项任务的可行性，在一些情况下，工具会错误地识别出重大更改。
向团队成员、公众和其他相关人员传达更改的性质
常规提交规范无法满足团队成员和公众对更新日志和提交日志的不同需求。
触发构建和发布流程
这是个糟糕的主意，可能会让自动化工具被绕过，需要人工来识别问题。
通过提供更结构化的提交历史，让人们更轻松地为你的项目做出贡献
提交历史确实更结构化了，但并不能让贡献变得更容易。常规提交规范的所有“卖点”都站不住脚，而且在项目中也极难应用。
更好的方法
不妨借鉴 Linux、FreeBSD、Git、Go 和 NixOS 等真正成功的软件项目的做法，它们都使用带作用域前缀的提交信息。以下是一些项目及其提交格式指南的示例：
| 项目 | 格式 | 示例 |
|---|---|---|
| Linux | `子系统: 描述` | `i2c: virtio: mark device ready before registering the adapter` |
| FreeBSD | `前缀: 描述` | `linuxulator: Return EINVAL for invalid inotify flags` |
| Git | `区域: 描述` | `gitlab-ci: update macOS image` |
| Go | `包: 描述` | `net/http/cookiejar: add godoc links` |
| nixpkgs | `包名: 描述` | `xwayland: 24.1.11 -> 24.1.12` |
| Node.js | `子系统: 描述` | `stream: fast-path stateless transform flush results` |
遗憾的是，尽管这种提交风格被一些有史以来最成功的开源项目所采用，但在品牌竞争中似乎败下阵来。作者打算改变这一现状，介绍 scopedcommits.com，该网站致力于倡导回归合理的提交信息编写方式，并将更新日志生成与提交日志管理的关注点分开。
结论
常规提交规范所谓的优势实际上是虚幻的，行业采用这一标准并未获得任何实际益处。作者写这篇文章的目的是挑战常规提交规范的主导地位，并展示有更好的方式来构建提交信息。
