什么是Conventional Commits
Conventional Commits 不是一个具体的代码库工具，而是一套用于编写 Git 提交信息的约定格式。它要求提交信息遵循统一结构：先写类型，必要时补充作用范围，再用一句简短描述概括本次变更；如果需要，还可以继续写正文和脚注。最常见的形式是“type(scope): description”，例如新增功能用 feat，修复问题用 fix，文档更新用 docs。相比随意写一句“update”或“modify”，这种方式更强调提交的含义、影响范围和可追踪性。
这套规范的价值不只在于“看起来整齐”。证据中明确提到，它直接服务于自动化变更日志生成、语义化版本控制以及更清晰的提交历史。也就是说，当团队长期坚持使用 feat、fix 和 BREAKING CHANGE 这类标准标记后，很多围绕发布流程的工作就能建立在提交记录之上：哪些提交属于新功能，哪些是补丁修复，哪些会带来不兼容变更，都能被工具更稳定地识别。
Conventional Commits 还对写法给出了较细的边界：描述应紧跟在冒号和空格之后，使用祈使语气，首字母不大写，不以句号结尾，并尽量保持简洁；正文如果存在，应与标题空一行，重点解释“改了什么、为什么改”，而不是展开实现细节；如果涉及破坏性变更，可以在类型或作用域后加“!”，也可以在脚注中单独写 BREAKING CHANGE。这些规则让提交信息不只是“留个痕迹”，而是成为项目协作中的结构化信息。
核心功能特点
- 用统一的“类型 + 可选范围 + 描述”结构规范所有提交信息，降低历史记录的阅读门槛
- 内置 feat、fix、docs、refactor、perf、test、ci、chore、revert 等常见类型，便于快速归类变更
- 明确要求使用祈使语气、简洁描述和可选正文，强调说明“改了什么、为什么改”
- 支持通过“!”或 BREAKING CHANGE 脚注标记破坏性更新，方便识别重大版本变更
- 与语义化版本控制直接对应：fix 通常关联 PATCH，feat 关联 MINOR，破坏性变更关联 MAJOR
适用场景
它最适合用在需要长期维护提交历史的代码仓库中。无论是个人项目还是多人协作，只要开发过程依赖 Git，提交信息迟早会变成排查问题、回顾需求和整理发布说明的重要依据。此时，Conventional Commits 的作用就很直接：团队成员看到“feat(auth): add OAuth2 support”或“fix(api): resolve token expiration issue”时，几乎不需要额外猜测就能知道这次提交属于什么类型、落在哪个模块、解决了什么问题。相比笼统的“修一下登录”“更新代码”，这种信息密度更高，也更利于后续检索。
它尤其适合已经把发布流程和自动化工具串起来的团队。证据包中明确指出，这种规范能支持自动生成变更日志和语义化版本控制，因此当项目需要定期发版、维护 CHANGELOG，或者希望根据提交自动判断版本号变更级别时，Conventional Commits 就能提供稳定输入。比如只看提交类型，工具就可以把 fix 归入补丁更新，把 feat 归入新功能，把 BREAKING CHANGE 单独标出来，减少人工整理版本说明的负担。
在代码审查、合并请求和发布前整理阶段，这套规范也很实用。它不仅适用于平时手动提交，也适用于生成提交信息、处理合并提交，甚至在用户讨论“这条 commit 该怎么写”时都能作为统一参照。对于较大的代码库，可选的 scope 能帮助团队把变更进一步定位到 parser、auth、readme 这类具体区域；而当提交必须说明兼容性风险时，使用“!”或 BREAKING CHANGE 脚注，也能提醒维护者提前评估升级影响，避免重要变更被埋在普通提交里。