核心用法
Conventional Commits 是一套业界广泛采用的 Git 提交信息规范，通过结构化格式实现版本控制自动化。核心结构为 <type>[optional scope]: <description>，配合可选的 Body 和 Footer 部分。
关键类型：feat（新功能，对应 MINOR 版本）、fix（修复，对应 PATCH 版本）为必用类型；扩展类型包括 docs、style、refactor、perf、test、build、ci、chore、revert 等，覆盖完整开发场景。
作用域（Scope）：可选字段，用于标识代码模块，如 feat(auth): add OAuth2 support，提升大型项目变更追踪效率。
破坏性变更：通过 ! 标记（如 feat!:）或 BREAKING CHANGE 脚注声明，自动触发 MAJOR 版本升级。
显著优点
1. 自动化集成：直接驱动 semantic-release、standard-version 等工具自动生成 CHANGELOG 和执行语义化版本发布
2. 可读性强：提交历史清晰分类，大幅降低 Code Review 和故障排查成本
3. 工具生态成熟：VS Code、IntelliJ、GitKraken 等主流 IDE 原生支持；Commitizen、Husky 可强制校验提交格式
4. 语义化版本关联：fix→PATCH、feat→MINOR、BREAKING→MAJOR，消除人为版本决策失误
5. CI/CD 友好：支持基于提交类型的自动化工作流触发（如仅 docs 变更跳过测试）
潜在缺点与局限性
- 学习成本：团队成员需熟悉类型定义和格式要求，初期可能产生合规摩擦
- 过度规范化风险：小型项目或个人开发可能感到约束过重
- 类型争议：
chore与refactor、style与refactor边界模糊，团队需制定内部约定 - 非代码变更盲区：设计文档、产品需求等非代码资产难以纳入此规范
适合人群
- 采用语义化版本（SemVer）的 Node.js/JavaScript 项目团队
- 需要自动生成 CHANGELOG 的开源项目维护者
- 多人协作的中大型工程团队，追求提交历史可追溯性
- 已配置 CI/CD 流水线、追求发布自动化的 DevOps 实践者
常规风险
| 风险项 | 说明 |
|--------|------|
| 格式误用 | 过去时、首字母大写、句尾句号等常见错误导致解析失败 |
| 类型选择随意 | 滥用 `chore` 掩盖实际变更性质，削弱自动化价值 |
| 破坏性变更遗漏 | 未显式标记 BREAKING CHANGE 导致意外 major 升级或用户故障 |
| 工具依赖单一 | 过度依赖特定生成工具，迁移成本上升 |
建议：结合 commitlint + husky 在本地强制校验，配合 CI 阶段二次检查，确保规范落地。