目前很多的项目都已经使用 Git 作为版本控制工具,使用 Git 意味着我们每天都要与 Git Commit Message 打交道。Git Commit Message 看似简单,但实际却很重要。通过 Git Commit Message 我们可以快速地了解本次提交的信息,比如解决了哪个 Bug、优化了什么问题或新增了什么功能等。
俗话说得好,无规矩不成方圆。因为 Git Commit Message 很重要,所以为了能够更好地进行项目开发与维护,我们就需要规范化 Git Commit Message,除此之外,规范化 Git Commit Message 还有以下的好处,比如:
那么应该如何规范化 Git Commit Message,这里我们可以使用开源社区为我们总结出了一套名为 Conventional Commits 的书写规范,该规范受到了 Angular Commit Guidelines 的启发,并在很大程度上以其为依据。它规定的格式如下:
<type>[optional scope]: <description>
[optional body]
[optional footer]
type 用于表示此次改动的类型,目前常用的主要有以下几种:
MINOR
相对应)PATCH
相对应)scope:一个可选的修改范围,用于标识此次提交主要涉及到代码中哪个模块。
description:简明扼要描述本次提交的内容,首字母无需大写,结尾不需要使用 .
。
optional body:详细描述本次提交,比如此次变更的动机,如需换行,则使用 |
。
optional footer:描述与之关联的 issue 或 break change。
feat: allow provided config object to extend other configs
BREAKING CHANGE: `extends` key in config file is now used for extending other config files
docs: correct spelling of CHANGELOG
feat(lang): added polish language
fix: minor typos in code
see the issue for details on the typos fixed
fixes issue #12
现在 Git Commit Message 规范已经找到了,但仅仅靠规范还是不能保证项目中的每个成员都遵循规范。这时我们还需要一个工具,能够智能地检测我们的 commit message 是否符合规范的要求。值得庆幸的是,现在已经有现成的工具了,它就是 commitlint,接下来我们来介绍在项目中如何使用 commitlint。
首先我们要先安装 commitlint 以及 conventional 规范:
# Install commitlint cli and angular config
$ npm install --save-dev @commitlint/{config-conventional,cli}
# For Windows:
$ npm install --save-dev @commitlint/config-conventional @commitlint/cli
接着在命令行输入以下命令:
echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js
运行以上命令后项目会生成 commitlint.config.js。当然我们也可以手动创建 commitlint.config.js 文件,然后在文件内输入以下内容:
module.exports = {extends: ['@commitlint/config-conventional']}
现在我们已经完成了 commitlint 的配置,但我们还需要在每次提交时,自动触发 commitlint 进行规范检查。要实现这个功能,我们可以借助另一个工具 husky。
? Git hooks made easy Husky can prevent bad
git commit
,git push
and more ? woof!
husky 是一个增强的 git hooks 工具,它让我们可以在 git hook 的各个阶段运行 package.json 中设定的任务。
下面我们继续来安装 husky:
$ npm install --save-dev husky
安装完成后,我们需要在 package.json 文件中添加以下的配置项:
"husky": {
"hooks": {
"commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
}
}
完成上述的配置后,我们可以验证一下 commitlint 是否生效:
$ git commit -m "foo: this will fail"
以上命令运行后,会输出以下信息:
husky > commit-msg (node v9.11.0)
⧗ input:
foo: this will fail
✖ type must be one of [build, chore, ci, docs, feat, fix, perf, refactor, revert, style, test] [type-enum]
✖ found 1 problems, 0 warnings
husky > commit-msg hook failed (add --no-verify to bypass)
$ git commit -m "chore: lint on commitmsg"
以上命令运行后,会输出以下信息:
usky > commit-msg (node v9.11.0)
⧗ input: chore: lint on commitmsg
✔ found 0 problems, 0 warnings
[master 394dce6] chore: lint on commitmsg
如果我们项目的 Git Commit Message 严格遵守 conventional 规范,那么在发布版本时,我们就可以自动生成 CHANGELOG,这里我们可以使用的是 standard-version 这款工具。
? Replacement for
npm version
with automatic CHANGELOG generation
顾名思义,standard-version 用于替代 npm version
,同时还能自动生成 CHANGELOG。最后,我们来简单介绍一下 standard-version 这款工具。
在介绍 standard-version 之前,我们先来简单了解一下 Semver(Semantic Versioning) 规范,该规范规定了版本号如何表示,如何增加,如何进行比较,不同的版本号意味着什么。
版本格式:主版本号.次版本号.修订号,版本号递增规则如下:
先行版本号及版本编译信息可以加到 “主版本号.次版本号.修订号” 的后面,作为延伸。Semver 规范中使用alpha、beta、rc 来修饰即将要发布的版本。它们的含义是:
在发布 npm 包时,为了让我们更好的遵从 Semver 规范,npm 为我们提供了 npm version 命令,具体使用方式如下:
关于 Semver(语义化版本号) 的相关内容,这里我们不再详细展开。感兴趣的同学,可以阅读 腾讯IVWEB团队 发布的 Semver(语义化版本号)扫盲 这篇文章。接下来我们开始介绍 standard-version 这款工具。
首先以 local 模式安装 standard-version:
$ npm install --save-dev standard-version
然后在 package.json 的 scripts 中添加以下配置:
{
"scripts": {
"release": "standard-version"
}
}
若需要发布首个版本,则可以运行以下命令:
$ npm run release -- --first-release
如果需要发布预发布版本,则可以使用 --prerelease
标志,比如:
$ npm run release -- --prerelease
假设你当前最新的版本是 v1.0.0
,在运行上述命令后,你的版本将变为 v1.0.1-0
。此外,如果你的预发布版本要包含 alpha
前缀,你可以通过 --prerelease <name>
设定前缀:
$ npm run release -- --prerelease alpha
此时,当前版本将变为 1.0.1-alpha.0
。除了 --first-release
和 --prerelease
标识外,standard-version 还支持一个很有用的标志 --release-as
,它支持三种不同的参数: major
, minor
或 patch
,使用方式如下:
$ npm run release -- --release-as minor
为了方便地进行版本发布,我们也可以在 npm scripts 中定义对应的任务,比如:
{
"release:minor": "standard-version --release-as minor && git push --follow-tags origin master",
"release:major": "standard-version --release-as major && git push --follow-tags origin master"
}