约定式提交
遵循 Conventional Commits v1.0.0 规范编写提交信息，以实现结构化的提交历史、自动化的变更日志生成和语义化版本控制。
何时使用此技能
在以下场景中使用此技能：
- 为结构化的项目创建 Git 提交信息
- 验证提交信息格式是否符合 Conventional Commits 规范
- 使用 commitlint 设置提交信息验证
- 从提交历史配置变更日志生成
- 实现语义化版本自动化
- 审查提交信息是否符合规范
- 培训团队掌握提交信息标准
- 与 semantic-release、commitizen 或 git-cliff 等工具集成
信息结构
<类型>[可选作用域]: <描述>
[可选正文]
[可选脚注]
组成
| 组成部分 | 必需 | 描述 | 示例 |
|---|---|---|---|
| 类型(type) | 是 | 提交类别 | feat、fix、docs |
| 作用域(scope) | 否 | 受影响的代码库部分 | (auth)、(parser) |
| 描述(description) | 是 | 变更的简短摘要 | 添加用户认证 |
| 正文(body) | 否 | 详细说明 | 多段上下文描述 |
| 脚注(footer) | 否 | 破坏性变更、问题引用 | BREAKING CHANGE:、Refs: #123 |
提交类型
必需类型（SemVer 影响）
以下类型是 Conventional Commits 规范所要求的，并直接影响语义化版本：
flowchart LR
Fix[fix: 用户错误修复] --> PatchVer[补丁版本<br/>0.0.X]
Feat[feat: 用户新功能] --> MinorVer[次版本<br/>0.X.0]
Breaking[任何类型含有<br/>BREAKING CHANGE 或 !] --> MajorVer[主版本<br/>X.0.0]
style PatchVer fill:#e1f5ff
style MinorVer fill:#fff4e1
style MajorVer fill:#ffe1e1
| 类型 | 描述 | SemVer | 示例 |
|---|---|---|---|
feat | 为用户添加新功能 | 次版本 (0.X.0) | feat: add user authentication |
fix | 为用户修复错误 | 补丁版本 (0.0.X) | fix: prevent crash on empty input |
推荐类型（Angular 约定）
以下类型来源于 @commitlint/config-conventional，基于 Angular 提交指南。除非包含 BREAKING CHANGE，否则它们没有隐式的 SemVer 影响。
| 类型 | 描述 | 示例 |
|---|---|---|
build | 构建系统或外部依赖变更 | build: update webpack to v5 |
ci | CI 配置变更 | ci: add Node 18 to test matrix |
docs | 仅文档变更 | docs: update API reference |
perf | 性能提升 | perf: reduce bundle size by 20% |
refactor | 代码变更（无错误修复或功能添加） | refactor: extract validation logic |
style | 代码样式变更（空白、格式） | style: fix indentation |
test | 添加或修正测试 | test: add unit tests for parser |
其他常见类型
| 类型 | 描述 | 示例 |
|---|---|---|
chore | 不修改 src 或测试文件的变更 | chore: update .gitignore |
revert | 回滚之前的提交 | revert: feat: add user auth |
注意：团队可以定义除 feat 和 fix 之外的自定义类型，但 Angular 约定类型在工具链中得到广泛支持。
规范规则
以下规则构成官方 Conventional Commits 1.0.0 规范，依据 RFC 2119。
类型和作用域
-
提交必须以类型为前缀，该类型由一个名词（
feat、fix等）组成，后跟可选的作用域、可选的!，以及必需的冒号和空格。 -
当提交添加新功能时，必须使用类型
feat。 -
当提交表示错误修复时，必须使用类型
fix。 -
类型后可以提供作用域。作用域必须由一个描述代码库部分的名词组成，并放在括号内，例如：
fix(parser): -
在类型/作用域前缀之后的冒号和空格之后，必须紧跟描述。描述是代码变更的简短摘要，例如：
fix: array parsing issue when multiple spaces were contained in string
正文
-
在简短描述之后可以提供更长的提交正文，以提供额外的上下文信息。正文必须在描述之后空一行开始。
-
提交正文是自由格式的，可以由任意数量的换行分隔的段落组成。
脚注
-
在正文之后空一行可以提供一个或多个脚注。每个脚注必须由一个单词标记组成，后跟
:<space>或<space>#分隔符，再跟一个字符串值（灵感来自 git trailer 约定）。 -
脚注的标记必须使用
-代替空白字符，例如：Acked-by（这有助于将脚注部分与多段落正文区分开）。例外：BREAKING CHANGE也可以用作标记。 -
脚注的值可以包含空格和换行。解析必须在观察到下一个有效的脚注标记/分隔符对时终止。
破坏性变更
-
破坏性变更必须在提交的类型/作用域前缀中指示，或者在脚注中作为条目指示。
-
如果作为脚注包含，破坏性变更必须由大写文本
BREAKING CHANGE组成，后跟冒号、空格和描述，例如：BREAKING CHANGE: environment variables now take precedence over config files -
如果在类型/作用域前缀中包含，破坏性变更必须通过在
:之前添加!来指示。如果使用了!，则可以从脚注中省略BREAKING CHANGE:，并且提交描述应用于描述破坏性变更。
附加规则
-
除了
feat和fix之外的类型可以在提交信息中使用，例如：docs: update ref docs -
构成 Conventional Commits 的信息单元不得被实现者视为大小写敏感的，但
BREAKING CHANGE必须大写。 -
当
BREAKING-CHANGE用作脚注中的标记时，必须与BREAKING CHANGE同义。
描述最佳实践
基于 Angular 提交信息指南：
摘要/描述指南
- 使用祈使句、现在时：