【Git】Conventional Commit 约定式提交规范

定义

在 git 代码提交的时候，我们需要对 git 的提交信息做出一定的约定或者规范。为什么会有这样的需求？因为 git 提交时的描述信息，需要在你的合作开发者之间共享，所以大多数情况下 git 提交信息并不只能被你一个人明白。于是就诞生了约定式提交这样的规范。

业内普遍认可的的约定式提交规范，为 约定式提交 (Conventional Commits)。

约定式提交规范 Conventional Commits 是一种用于给提交信息增加人机可读含义的规范，是基于提交信息的轻量级约定，提供了一组用于创建清晰的提交历史的简单规则。

它可以利用几组简单的规则来创建清晰的提交历史，这样更有利于编写自动化工具和创建更加结构化的提交历史。

它提供的简单提交说明结构如下：

<类型>([可选的作用域]): <描述>

[可选的正文]

[可选的脚注]

使用

使用的时候，通常遵循以下几个步骤：

// 选择一个提交的类型
1. select the type of change that you're committing

// 更改影响的范围，可不填；如果使用，需要加上()包裹
2. What is the scope of this change (e.g. component or file name): (press enter to skip)

// 简短的描述，使用英文半角冒号+空格隔开
3. Write a short, imperative tense description of the change (max 88 chars)

// 具体描述
4. rovide a longer description of the change: (press enter to skip)

// 是否有破坏性的更改，如果是，则使用 BREAKING CHANGE 标注提交信息
5. Are there any breaking changes?

// 是否有关联性的问题
6. Does this change affect any open issues?

提交的时候，选择的类型通常有以下几种：

feat 表示新增了一个功能

`fix 表示修复了一个 bug

docs 只涉及到文档的更改

style 不影响代码语义的变化（格式化等类型）

refactor 代码重构，既不修复错误也不添加功能

perf 改进性能的代码更改

test 添加确认测试或更正现有的测试

`build 影响构建系统或外部依赖关系的更改

ci 更改持续集成文件和脚本

chore 其他不修改src或test`文件

revert 回退 commit

在提交 log 的时候，按照需要选择提交的时候，应该为以下这种形式的格式：

// 包含作用域的提交
feat(login.vue): add login view 
perf(permission.js): remove useless code
// 其他类型的提交
docs: update README.md

规范检测

此外，为了检查自己的提交是否符合规范，可以安装 commitizen 和 cz-customizable 插件来使用。如果不符合规范，那么提交将会失败。

如果你恰好使用的是 vscode ，那么可以在插件市场下载 vscode commitizen 插件。这样可以摆脱命令行的限制，而且会提交可视化界面给你选取合适的 Conventional Commits 类型。如果使用的是 jetbrains 系列的 IDE ，也可以在插件市场下载 Git Commit Template 或者 Conventional Commit 插件。以前者为例，可以直接提供模板，页面如下所示：

作用

• 自动化生成 CHANGELOG。
• 基于提交的类型，自动决定语义化的版本变更。
• 向同事、公众与其他利益关系者传达变化的性质。
• 触发构建和部署流程。
• 让人们探索一个更加结构化的提交历史，以便降低对你的项目做出贡献的难度。