提交信息组成部分详解

更新: 1970/1/1 字数: 0 字 时长: 0 分钟

1. 类型 (Type)

类型是必填项，用于说明本次提交的性质。必须是以下标识符之一：

类型	描述
feat	新功能 - 新增了一个功能。
fix	Bug 修复 - 修复了一个 Bug。
docs	文档 - 仅修改了文档（如 README.md）。
style	代码样式 - 修改了代码格式、样式（空格、分号等），不改变代码逻辑。
refactor	代码重构 - 既不是修 Bug 也不是加功能的代码修改（重构、优化等）。
perf	性能优化 - 提升性能的代码更改。
test	测试 - 增加或修改测试用例。
build	构建系统 - 影响构建系统或外部依赖的更改（如 npm、gulp、webpack）。
ci	CI 配置 - 更改持续集成相关的配置和脚本（如 Travis、GitHub Actions）。
chore	杂项 - 其他不修改源代码或测试文件的更改（如更新构建任务、包管理器配置）。
revert	回滚 - 撤销某次提交。

2. 范围 (Scope)

• 可选项。用于描述提交影响的范围，是一个名词。
• 它应该放在类型后面的括号内，例如 feat(parser):。
• 范围可以是特定的模块、组件、文件或功能点，例如：
  • auth
  • router
  • ui/button
  • docs
• 如果修改影响多个范围，可以使用 *，但应尽量避免。

3. 描述 (Description)

• 必填项。对本次代码变更的简短描述。
• 使用祈使句、现在时态，例如 “change” 而不是 “changed” 或 “changes”。
• 首字母不要大写。
• 不要在末尾添加句号（.）。
• 长度建议控制在 50 个字符以内。

4. 正文 (Body)

• 可选项。用于提供更详细的说明，解释为什么要进行这个更改，而不是做了什么（代码本身已经说明了做了什么）。
• 与描述之间用一个空行隔开。
• 正文可以有多段，每行 wrap 在 72 个字符左右。
• 同样使用祈使句、现在时态。

5. 脚注 (Footer)

• 可选项。放置一些元数据或说明。
• 与正文之间用一个空行隔开。
• 通常用于两种情况：
  • ** breaking changes（重大变更）**：以 BREAKING CHANGE: 开头，后面跟对变更的描述以及迁移指南。这会触发主版本号升级。
  • 关闭 Issue：引用相关的 Issue，例如 Closes #123 或 Fixes #456, #789。

Breaking Changes（重大变更）

如果本次提交包含不向后兼容的变更（API 变更、数据库结构变更等），必须在正文或脚注中明确说明

说明必须以 BREAKING CHANGE: 开头，后面跟一个空格或换行，然后是对变更的详细描述