文章批评了流行的"约定式提交"(Conventional Commits)标准，认为它虽然被许多开源项目采用，但实际上是一个糟糕的标准。作者指出该标准会引导开发者关注错误的事情，弊大于利，并明确表示反对使用这种提交规范。

标题：停止使用约定式提交

文章核心观点： 1. 约定式提交（Conventional Commits）存在根本性缺陷： - 错误地将提交类型（type）置于变更范围（scope）之上，而实际开发中scope才是最重要的信息 - 强制要求的type字段往往是冗余的，且会限制开发者表达复杂的变更性质

2. 约定式提交的承诺未能兑现：

• 自动生成变更日志（CHANGELOG）的效果不佳，因为提交日志和用户变更日志的受众需求完全不同
• 自动语义化版本控制不可靠，容易因代码回退、意外破坏性变更等情况导致版本号错误
• 其他宣称的优点（如触发构建流程、便于贡献等）也都存在明显问题

3. 更优的替代方案：

• 推荐采用"范围前缀式提交"（如Linux、Git等成功项目使用的格式）
• 典型格式为：scope: description，其中scope根据项目特点自然确定（如子系统、包名等）
• 作者为此创建了scopedcommits.com网站推广这种提交规范

4. 结论：

• 约定式提交已成为行业反模式，但仍在开源社区流行
• 呼吁开发者转向更合理的提交消息规范

（注：删减了部分重复论证和示例链接，保留了核心论点和关键论据）

以下是评论内容的总结，按观点分类呈现：

【支持传统提交规范的观点】 1. 历史追溯价值 - "作为独立开发者，我很少记不住昨天修改了什么，但经常记不住六个月前为何做某个决定" (评论1) - "项目越大，这种上下文就越有用" (评论1)

2. 自动化发布优势

• "传统提交真正有用的是持续交付，每次合并到主分支都能自动打上语义化版本标签" (评论10)
• "提交类型告知自动化工作流如何处理提交，这就是它放在首位的原因" (评论12)

3. 规范约束作用

• "有规范至少能迫使人们写出经过思考的单行描述" (评论26)
• "我没有精力监管糟糕的提交信息，用CC规范可以通过仓库合并策略轻松执行" (评论28)

【反对传统提交规范的观点】 1. 类型标签冗余 - "提交类型几乎不能提供任何信息，只是浪费我跳过它的时间" (评论8) - "Linux内核风格的提交主题更好：子系统: 描述" (评论23)

2. 关键信息缺失

• "我的主要抱怨是传统提交不包含问题编号" (评论7)
• "唯一有用的就是关联变更请求的链接/ID，文章甚至没考虑这点" (评论24)

3. 结构设计缺陷

• "标准要求深思熟虑，'feature'缩写而'refactor'不缩写，说明缺乏设计思考" (评论2)
• "它占用消息最常阅读部分的空间，类别信息量很少" (评论21)

【中立/替代方案观点】 1. 强调变更说明 - "任何标记都应服务于特定用例并适应其领域" (评论15) - "我更希望人们深入思考如何总结工作，这比强制格式更有帮助" (评论27)

2. 使用git trailers

• "如果需要元数据，通常最好放在git trailer中" (评论13)
• "想要机器可读？使用页脚/尾注" (评论21)

3. 变更日志建议

• "生成变更日志会导致用户困惑，精心整理的变更摘要更符合预期" (评论22)
• "维护变更日志有更简单的方式：直接维护一个变更日志" (评论14)

关键分歧点： • 支持方认为规范提供历史追溯和自动化价值 • 反对方认为强制格式占用空间且信息量低 • 第三方建议更灵活的替代方案

典型引用对比： 支持规范： "传统提交结合语义化版本能极大改善99%项目的发布流程" (评论10)

反对规范： "'修复'或'特性'标签毫无价值，重要的是内容就不会被提交" (评论24)

替代方案： "Linux内核风格'subsystem: description'比强制类型更有用" (评论23)