Conventional Commits

核心用法

Conventional Commits 是一套标准化的 Git 提交信息规范，强制要求所有 commit 消息遵循特定格式：<type>[optional scope]: <description>。该 skill 提供完整的类型定义（feat/fix/docs/style/refactor/perf/test/build/ci/chore/revert）、作用域规范、正文与页脚编写指南，以及破坏性变更标记方式（! 符号或 BREAKING CHANGE 页脚）。

显著优点

• 自动化工具链集成：直接驱动 semantic-release、standard-version 等工具自动生成版本号和 CHANGELOG
• 语义化版本映射：fix→PATCH、feat→MINOR、BREAKING CHANGE→MAJOR，版本策略清晰可追溯
• 历史可读性提升：结构化格式使提交历史一目了然，大幅降低代码审查和回滚成本
• 多语言社区广泛采用：被 Angular、Vue、React、Jest 等主流开源项目采纳，生态成熟

潜在局限

• 学习成本：团队成员需记忆类型定义和格式规则，初期可能产生抵触
• 灵活性受限：严格格式要求对复杂变更的描述能力有限，需配合 body/footers 补充
• 工具依赖：完整价值需配合自动化工具实现，裸用规范收益有限
• 非代码变更标注模糊：chore 类型成为"垃圾桶"，容易堆积杂项提交

适合人群

• 采用语义化版本控制的软件项目团队
• 需要自动化发布流程的 DevOps 团队
• 开源项目维护者（尤其 Node.js/JavaScript 生态）
• 多人协作、代码审查频繁的中大型工程

常规风险

• 类型误用导致版本号错误发布（如将 breaking change 标为 feat）
• 作用域命名不一致削弱分类价值
• 过度依赖自动化可能忽视人工审查的重要性
• 与未采用该规范的外部贡献者协作时产生摩擦

核心用法

Conventional Commits skill 是一套纯文档型的提交信息格式化规范，指导用户按照标准结构编写 Git 提交信息。

核心结构：

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

主要类型：

• feat: 新功能（对应 MINOR 版本）
• fix: 修复缺陷（对应 PATCH 版本）
• docs: 文档变更、style: 代码格式、refactor: 重构、perf: 性能优化、test: 测试、build: 构建系统、ci: CI配置、chore: 杂项、revert: 回退

关键规范：

• 描述使用祈使语气（"add" 而非 "added"）
• 首字母小写，结尾无句号
• 长度控制在 50-72 字符
• 破坏性变更用 ! 标记或 BREAKING CHANGE 页脚
• Body 解释"做什么"和"为什么"，而非"怎么做"

显著优点

1. 自动化生态兼容：原生支持 semantic-release、commitlint、standard-version 等主流工具链
2. 清晰的变更历史：结构化的提交信息便于快速追溯代码演进
3. 版本自动化：提交类型直接映射 SemVer 规则，实现版本号自动推导
4. 团队协作友好：统一格式降低代码审查成本，新人 onboarding 更快
5. 零执行风险：纯 Markdown 文档，无可执行代码，无需担心安全问题

潜在局限

1. 学习成本：团队成员需要适应新的书写习惯，初期可能产生格式错误的提交
2. 灵活性受限：严格格式对某些复杂变更的描述可能显得冗长
3. 工具依赖：要发挥自动化价值，需配套配置 commitlint 等工具
4. 中文支持一般：规范本身英文导向，中文项目使用需约定本地化规则

适合人群

• 需要自动化版本管理和变更日志生成的团队
• 采用语义化版本控制（SemVer）的开源/商业项目
• 多人协作、重视代码历史可追溯性的工程团队
• 使用 Angular、React、Vue 等已采用该规范的生态的开发者

常规风险

• 格式一致性风险：若无 CI 强制检查，可能出现格式混乱的提交
• 类型选择争议：feat vs. fix vs. refactor 的边界有时模糊，需团队约定
• 过度提交碎化：为遵循"单逻辑变更"原则，可能导致提交过多难以阅读
• 破坏性变更遗漏：忘记标记 ! 或 BREAKING CHANGE 导致意外 major 版本发布

安全评估

该 Skill 为纯文档型，无可执行代码、无网络调用、无权限申请、无数据收集，安全评级 S+，完全可信。