Git 每次提交代码,都要写 Commit message(提交说明),否则就不允许提交。
一般来说,commit message 应该清晰明了,说明本次提交的目的,是新增了一个功能或者修复了一个bug 之类的,但是随着项目组人员增多,仅靠口头的约束有时候还是会出错的,所以我们需要通过工具来帮助规范团队的 commit message。
规范的 commit message
每次提交,Commit message 都包括三个部分:Header,Body 和 Footer。
其中,Header 是必需的,Body 和 Footer 可以省略。
不管是哪一个部分,任何一行都不得超过72个字符(或100个字符)。这是为了避免自动换行影响美观。
1 | <type>(<scope>): <subject> |
Header
Header部分只有一行,包括三个字段:type
(必需)、scope
(可选)和 subject
(必需)。
type
type
用于说明 commit 的类别,可以使用以下标识
1 | feat:新功能(feature) |
如果 type
为 feat
和 fix
,则该 commit 将肯定出现在 Change log 之中。其他情况默认不加入,可以修改,建议不要。
scope
scope
用于说明 commit 影响的范围,比如数据层、控制层、视图层等等,视项目不同而不同。
subject
subject
是 commit 目的的简短描述,不超过50个字符。有以下限制
1 | 以动词开头,使用第一人称现在时,比如change,而不是changed或changes |
Body
Body 部分是对本次 commit 的详细描述,可以分成多行。使用 git commit
会弹出多行编辑器
有两个注意点。
- 使用第一人称现在时,比如使用
change
而不是changed
或changes
。 - 应该说明代码变动的动机,以及与以前行为的对比。
Footer
Footer 部分只用于两种情况。
不兼容变动
如果当前代码与上一个版本不兼容,则 Footer 部分以 BREAKING CHANGE
开头,后面是对变动的描述、以及变动理由和迁移方法。
关闭 Issue
如果当前 commit 针对某个issue,那么可以在 Footer 部分关闭这个 issue 。
1 | fix #1 |
validate-commit-msg
validate-commit-msg
是什么?
一个可以校验 commit message 的二进制文件
安装 validate-commit-msg
1 | npm install validate-commit-msg --save-dev |
validate-commit-msg
的配置可以通过项目根目录下的 .vcmrc
文件,或者在 package.json
中修改
.vcmrc 文件内容是一个正确的 json 格式
validate-commit-msg
提供了默认配置,一般项目开发不需要修改这个
1 | { |
在 package.json
中修改配置
1 | { |
.vcmrc
文件的优先级更高,如果.vcmrc
文件不存在,才会从package.json
中读取
husky
husky是什么?
husky 是一个 Git Hook 工具。husky 其实就是一个为 git 客户端增加 hook 的工具。将其安装到所在仓库的过程中它会自动在 .git/
目录下增加相应的钩子实现在 pre-commit
阶段就执行一系列流程保证每一个 commit
的正确性。
安装 husky
不同的包管理工具使用不一样的安装方法:官方文档
1 | npx husky-init && npm install # npm |
执行之后会在项目根目录生成 .husky
目录,目录下会有一个 pre-commit
文件,把文件中的 npm test
修改为 npm run lint
,如果你的项目中没有使用 eslint
,可以把这个文件直接改名成 commit-msg
,把文件中的 npm test
修改为 npx validate-commit-msg
。
将 pre-commit
文件复制两份命名为 commit-msg
和 pre-push
commit-msg
文件中的 npm run lint
修改为 npx validate-commit-msg
pre-push
文件中的 npm run lint
修改为 npm run test:unit
,如果你的项目没有使用单元测试可以不需要这个文件
- pre-commit 会在输入提交信息之前调用,校验 eslint
- commit-msg 输入了提交信息,如果校验出错,放弃提交
- pre-push git push 执行的时候 更新了远程引用但尚未推送到远程时被调用
测试一下 validate-commit-msg
和 husky
是否生效
回到项目根目录下执行
1 | git add . |
出现以下信息代表 commit-msg
钩子中执行的 validate-commit-msg
生效了
1 | AINVALID COMMIT MSG: does not match "<type>(<scope>): <subject>" ! |
做一次正确的提交,commit msg 应该必须包含 type
:
和 subject
,scope
是可选的
1 | git commit -m "chore: 添加husky和validate-commit-msg校验commit msg" |
Commitizen
Commitizen 是什么?
Commitizen 是一个撰写合格 Commit message 的工具。
安装 Commitizen
1 | npm install commitizen --save-dev |
初始化项目中使用 cz-conventional-changelog 适配器
1 | # npm 包管理工具执行 |
package.json
文件中会自动添加 commitizen
配置
1 | "config": { |
以后,凡是用到 git commit
命令,一律改为使用 cz
。这时,就会出现选项,用来生成符合格式的 Commit message。
测试一下
1 | git add . |
使用 git log
可以查看刚才的 commit message
还可以在 package.json
中添加更加方便的执行命令,在 package.json
的 scripts
中添加
1 | "cz": "cz", |
之后在提交代码,就可以在项目根目录下执行
1 | npm run commit |
生成 changelog
如果项目中所有的 commit 都是按照上述格式提交的,那么 change log
,就可以用脚本自动生成。
生成的文档包括以下三个部分。
1 | New features |
每个部分都会罗列相关的 commit ,并且有指向这些 commit 的链接。当然,生成的文档允许手动修改,所以发布前,你还可以添加其他内容。
conventional-changelog 就是生成 Change log 的工具
安装 conventional-changelog
1 | npm install conventional-changelog-cli --save-dev |
命令行执行以下命令就会在项目根目录下生成 CHANGELOG.md
1 | npx conventional-changelog -p angular -i CHANGELOG.md -s |
之后在发布新的版本的时候都可以使用这个命令,往 CHANGELOG.md
文件中,添加新版本的log
可以把这个命令添加到 package.json
中的 scripts
下,方便之后的使用
1 | "changelog": "conventional-changelog -p angular -i CHANGELOG.md -s" |
之后就可以使用以下命令往 CHANGELOG.md
文件中,添加新版本的log
1 | npm run changelog |
相关资料
阮一峰 Commit message 和 Change log 编写指南
完结
项目已经上传到 github 和 gitee
GitHub: https://github.com/wukang0718/cli-create-project
Gitee: https://gitee.com/wu_kang0718/cli-create-project
下一篇:集成axios