conventional-commits

核心用法

Conventional Commits 技能是一个纯文档型指导工具，旨在帮助开发者按照行业标准规范编写 Git 提交信息。该技能不提供可执行代码，而是通过详细的格式说明和示例，指导用户遵循 type[scope]: description 的标准结构。核心用法包括：识别提交类型（feat/fix/docs/style 等）、添加可选作用域、使用祈使语气编写描述、在需要时补充正文和页脚信息，以及正确标记破坏性变更（通过 ! 符号或 BREAKING CHANGE 页脚）。

显著优点

1. 行业标准背书：直接对接 Conventional Commits 官方规范，被 Angular、Vue.js 等主流项目广泛采用，具有高度权威性。
2. 自动化友好：规范化的提交信息可直接驱动语义化版本控制（Semantic Versioning）和自动化变更日志生成，大幅提升 DevOps 效率。
3. 零依赖零风险：纯 Markdown 文档技能，无可执行代码，不依赖任何外部服务或第三方包，部署和使用成本极低。
4. 全面覆盖：涵盖从基础格式到复杂场景（多段落正文、破坏性变更、多页脚）的完整示例，适合不同经验水平的开发者。

潜在缺点与局限性

1. 非强制执行：作为文档指导型技能，无法自动校验或阻止不符合规范的提交，依赖用户自觉遵守。
2. 学习成本：对于不熟悉 Conventional Commits 规范的团队，成员需要一定时间适应类型分类和格式要求。
3. 场景局限：仅适用于 Git 提交场景，无法覆盖代码审查、Issue 管理等更广泛的研发协作流程。
4. 版本滞后风险：若 Conventional Commits 规范更新，技能文档可能未能及时同步。

适合的目标群体

• 采用语义化版本控制的软件项目团队
• 需要自动化生成变更日志的开源项目维护者
• 希望统一代码提交规范的中小型研发团队
• 正在建立 DevOps 流程、追求研发自动化的技术组织

使用风险

该技能为纯文档类型，不存在代码执行、网络请求或文件系统访问等运行时风险。主要风险在于：团队成员对规范理解不一致导致执行偏差；长期未更新可能错过规范新版本特性；过度依赖规范而忽视提交信息的实际可读性价值。

核心功能

Conventional Commits 是一套开源的 Git 提交消息规范，通过预定义的类型前缀（如 feat:、fix:）和结构化格式，使提交历史具备机器可读性。该规范直接支撑语义化版本控制（Semantic Versioning）自动化：

• fix: 类型自动触发 PATCH 版本号递增
• feat: 类型自动触发 MINOR 版本号递增
• BREAKING CHANGE 标记自动触发 MAJOR 版本号递增

显著优势

1. 自动化工具链集成：与 semantic-release、commitlint、husky 等工具无缝配合，实现版本发布流水线全自动化
2. 变更日志生成：结构化格式支持工具自动生成 CHANGELOG.md，无需人工维护
3. 代码审查效率：提交类型一目了然，快速识别变更性质，降低 review 成本
4. 历史可追溯性：作用域（scope）机制精确定位代码模块变更，便于后期问题排查
5. 行业广泛采用：Angular、Vue、Jest 等主流开源项目均采用此规范，生态成熟

局限性与注意事项

• 学习成本：团队成员需理解类型定义与格式规则，初期可能产生格式错误提交
• 过度规范化风险：小型项目或单人项目使用可能增加不必要的流程负担
• 工具依赖：充分发挥价值需配合 husky、commitlint 等钩子工具，增加配置复杂度
• 中文支持局限：规范原生基于英文设计，中文团队需在描述语言风格上取得平衡

适用人群

• 采用语义化版本控制的团队协作项目
• 需要自动化发布流程的中大型代码库
• 开源项目维护者（提升贡献者体验）
• 对 Git 历史可追溯性有严格要求的工程团队

常规风险提示

该 Skill 本身为纯文档型规范说明，无代码执行风险。实际应用时的风险主要来自：

• 配置错误：commitlint 规则配置不当可能导致合法提交被拦截
• 自动化脚本风险：semantic-release 等关联工具的配置错误可能引发非预期版本发布
• 团队协作成本：未达成团队共识即强制执行可能引发协作摩擦

建议配合 CI/CD 流水线渐进式引入，初期采用推荐模式而非强制模式。