在现代软件开发流程中，规范化的提交信息对于项目管理、协作和自动化工具的有效运行至关重要。Conventional Commits作为一种旨在统一和标准化提交消息格式的规范，被广泛采用并推动了持续集成和自动发布等流程的自动化。然而，在长期使用和实际应用中，Conventional Commits也暴露出一些令人困扰的问题，令不少开发者感到不便甚至失望。本文从多个角度深入剖析这一规范所存在的不足，探讨它在人机交互和机器消费之间的平衡问题，并提出针对性的改进建议，希望为开发者社区和工具设计者提供启示。首先，Conventional Commits强制要求每条提交必须以类型（type）作为前缀，比如feat、fix等，并且紧随其后的是可选的作用域（scope）、可选的感叹号（!）表示重大变更，以及必须的冒号和空格。表面上看来，这种结构化的格式便于自动化分析和分类，尤其对持续集成系统的解析极为友好。
然而对开发者而言，这种格式的刚性限制却带来了不少痛点。提交信息不仅仅是标题，它应当是一条完整的思想表达，包括标题、主体和脚注。将类型强制绑定在开头并占用有限的字符长度，可能会限制开发者对变更内容的准确和清晰描述。此外，类型本质上常常是可以从提交摘要中推断出来的，因此将类型放在标题前缀处显得多余。作者建议，不如将类型作为提交消息脚注中的字段呈现，例如Commit-Type或Type键，这样既保留了自动化识别的便利，也避免了对提交标题的约束，使其更自然可读。其次，对于标记重大变更的感叹号（!）和BREAKING CHANGE脚注的设计也存在不一致和模糊的地方。
规范允许在类型/作用域前缀中以“！”表示存在重大变更，且可以省略脚注中BREAKING CHANGE字段。这样的设计增加了工具解析的复杂度，因为仅凭感叹号只能得知有破坏性变更，但具体原因还隐藏在一般的描述中，难以直接定位。更严重的是，重大变更的信息可能直到提交推送之后才被发现，若只能修改提交信息，加之git不鼓励频繁修改历史，就容易引发协作困扰。对此，作者提出使用git notes为提交补充上下文的方案，既保持提交历史稳定，又便于后续查阅。另一令作者感到不满的是脚注键名规范。Conventional Commits要求脚注键必须用“-”替代空白字符，比如Acked-by，但对于BREAKING CHANGE却破例允许空格。
这样不统一的设计显得不够严谨，令格式解析复杂化。统一键名格式，使BREAKING CHANGE变为Breaking-Change，能提升整体规范的一致性和易用性。Conventional Commits官网FAQ中的一些建议也引发了争议。比如，当发现输入了错误的提交类型时，官网建议在合并或发布前使用git rebase -i交互式变基编辑历史，发布后则需根据工具和流程不同处理。作者认为，尽管rebase是一种有效的变基手段，但很多开发者尤其新手并不熟悉交互式变基的具体操作，也难以实时获得详尽指导。官网若能提供更具体的指令说明或权威文档链接，会极大提升用户体验。
同时，若错误的提交是最近一条，使用git commit --amend即可，官网应明确强调这一快捷方式。此外，FAQ提出通过自动压缩（squash）合并拉取请求并由项目管理者填写规范提交信息，虽然看似简化流程，却会造成潜在问题。压缩合并使多个独立的提交合而为一，虽然提交历史更为简单，但信息往往会丢失，特别是在功能开发和重构混合的情况下，无法体现变更的细节和阶段。相反，应当鼓励尽可能保留多条相关但独立的提交，便于代码审查、回溯排查和责任追溯。综上所述，作者并非反对统一和标准化的提交信息规范，而是希望Conventional Commits能更注重人的可读性，兼顾机器的兼容性。作为软件工程中极为重要的沟通手段，提交信息不仅仅是给计算机看的元数据，更是团队成员之间、项目历史和未来维护者之间的桥梁。
因此，人优先、机兼容的原则应被摆在首位。希望未来的规范迭代能够强调更友好的设计，同时完善文档和工具支持，减轻开发者负担，提高代码仓库的整体质量和可维护性。通过合理的改进和调整，Conventional Commits可望真正成为连接代码变更与项目管理、自动化运行的高效纽带，而非令人烦恼的约束。
