Git 的提交使用 git commit -m "hello world" 来提交 comment，但是一些像 hello world 这样没有意义的 comment 让人无法理解这次的提交到底是为了什么，所以引入一致规范就显得相当重要。
这里我们使用是业界常用 Angular 规范 ，它有比较多的配套，个人推荐。
下面是一些基础介绍如果觉得麻烦直接查看第二部分：
1. commit message format(信息域)
commit message 一般分为三个部分 Header，Body 和 Footer
():
// 空一行
// 空一行
其中，Header 是必需的，Body 和 Footer 可以省略。
1.1 Header
type 用于说明 commit 的类别，只允许使用下面 7 个标识：
feat：新功能（feature）
fix：修补bug
docs：文档（documentation）
style： 格式（不影响代码运行的变动）
refactor：重构（即不是新增功能，也不是修改bug的代码变动）
test：增加测试
chore：构建过程或辅助工具的变动
-
scope用来说明本次 commit 影响的范围，即简要说明修改会涉及的部分，如某个模块，功能点等。 -
subject是本次 commit 的简短描述。
1.2 Body
是对本次 commit 的详细描述，可以分成多行。
1.3 Footer
这部分只用于两种情况：
- 不兼容变动
如果当前代码与上一个版本不兼容，则 Footer 部分以 BREAKING CHANGE 开头，后面是对变动的描述、以及变动理由和迁移方法。
- 关闭 Issue
如果当前 commit 针对某个 issue，那么可以在 Footer 部分关闭这个 issue (可依次关闭过个 issue Closes #123, #245, #992)。
1.4 Revert
还有一种特殊情况，如果当前 commit 用于撤销以前的 commit，则必须以 revert:开头，后面跟着被撤销 commit 的 Header
revert: type(scope): some comment
This reverts commit 32a9e889..3affe8a5.
Body 部分的格式是固定的，必须写成This reverts commit ，其中的 hash 是被撤销 commit 的 HASH 标识符。
如果当前 commit 与被撤销的 commit，在同一个发布（release）里面，那么它们都不会出现在 ChangeLog 里面。如果两者在不同的发布，那么当前 commit，会出现在 ChangeLog 的 Reverts 小标题下面。
2. 使用 commitizen 来执行规范
2.1 安装 node
官方地址
2.2 全局安装 commitizen 模块
npm install -g commitizen
在项目目录下运行命令：
commitizen init cz-conventional-changelog --save --save-exact
运行完以上一律使用 git cz 代替 git commit 来提交代码，同时会显示一下选项来自动生成符合格式的 commit message。
C:\dev\colorfuljs>git cz
[email protected], [email protected]
? Select the type of change that you're committing: build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
? What is the scope of this change (e.g. component or file name): (press enter to skip)
? Write a short, imperative tense description of the change (max 93 chars):
(14) add husky pnpm
? Provide a longer description of the change: (press enter to skip)
? Are there any breaking changes? No
? Does this change affect any open issues? No
[master ba9260c] build: add husky pnpm
5 files changed, 4277 insertions(+), 3305 deletions(-)
create mode 100644 .husky/commit-msg
create mode 100644 pnpm-lock.yaml
delete mode 100644 yarn.lock
按照提示，你可以写出规范的 message 了。
3. 强制执行规范
我们使用 commitizen 同时可以检查 commit message 是否符合格式，详情可以参考。但是跟你一同协作的小伙伴可能使用其他方式提交代码。既然规范，那大家一定要保持一致，可以通过 commitlint + husky 来解决。
3.1 使用 commitlint 来对 commit message 校验约束
先安装：
npm install --save-dev @commitlint/config-conventional @commitlint/cli
根目录下新建 commitlint.config.js 配置：
module.exports = {
extends: ['@commitlint/config-conventional']
}
代码中继承的就是 Angular 格式的配置，当然还有自定义规则，此处不列举。
3.2 使用 husky 来阻止不合规范的 commit message 提交
本方法针对的是 husky 7.x 版本，网上其他大都是 4.x 版本的。
再安装：
npm install --save-dev husky
安装 Git 挂钩，默认 .husky 目录：
npx husky install
把 Git 挂钩加入自动安装：
npm set-script prepare "husky install"
添加 commit-msg 钩子：
npx husky add .husky/commit-msg "npx --no-install commitlint --edit \"$1\""
至此提交校验规范大功告成。我们来尝试提交下错误规范信息来测试：
C:\dev\colorfuljs>git commit -m "debug husky"
⧗ input: debug husky
✖ subject may not be empty [subject-empty]
✖ type may not be empty [type-empty]
✖ found 2 problems, 0 warnings
ⓘ Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint
husky - commit-msg hook exited with code 1 (error)
再说个 husky 比较常用的 pre-commit 钩子，可以加入我们常用的 lint 或者 test unit。
npx husky add .husky/pre-commit "npm test"