管理工具
commitizen
安装
npm install -g commitizen cz-conventional-changelog
echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc
commitlint
安装
npm install --save-dev @commitlint/{config-conventional,cli} husky
@commitlint/cli: commitlint 的 CLI 工具
@commitlint/config-conventional: commitlint 的 conventional 规范配置方案，这是一个从 config-angular 衍生出的一个分支
husky: 一款 git hook 工具，可以 hook git 的命令
添加规范
echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js
@commitlint/config-conventional 是刚才安装的 commitlint 规范配置方案，可以安装并替换为其他的配置（例如 config-angular）。
添加commit钩子
{
"husky": {
"hooks": {
"commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
}
}
}
commit-msg 代表对 commit message 进行 hook，hook 的时候执行后面的命令 commitlint -E HUSKY_GIT_PARAMS 进行检查。
规则
默认规则
Commit message格式
<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>
分别对应 Commit message 的三个部分：Header，Body 和 Footer.
注意冒号后面有空格
使用
执行git cz进入interactive模式，根据提示依次填写
1.Select the type of change that you're committing 选择改动类型 (<type>)
2.What is the scope of this change (e.g. component or file name)? 填写改动范围 (<scope>)
3.Write a short, imperative tense description of the change: 写一个精简的描述 (<subject>)
4.Provide a longer description of the change: (press enter to skip) 对于改动写一段长描述 (<body>)
5.Are there any breaking changes? (y/n) 是破坏性修改吗？默认n (<footer>)
6.Does this change affect any openreve issues? (y/n) 改动修复了哪个问题？默认n (<footer>)
Header
Header部分只有一行，包括三个字段：type（必需）、scope（可选）和subject（必需）。
- type: 用于说明 commit 的类型。一般有以下几种:
feat: 新增feature
fix: 修复bug
docs: 仅仅修改了文档，如readme.md
style: 仅仅是对格式进行修改，如逗号、缩进、空格等。不改变代码逻辑。
refactor: 代码重构，没有新增功能或修复bug
perf: 优化相关，如提升性能、用户体验等。
test: 测试用例，包括单元测试、集成测试。
chore: 改变构建流程、或者增加依赖库、工具等。
revert: 版本回滚
-
scope: 用于说明 commit 影响的范围，比如: views, component, utils, test...
-
subject: commit 目的的简短描述
Body
对本次 commit 修改内容的具体描述, 可以分为多行。如下:
# body: 72-character wrapped. This should answer:
# * Why was this change necessary?
# * How does it address the problem?
# * Are there any side effects?
# initial commit
Footer
一些备注, 通常是 BREAKING CHANGE(当前代码与上一个版本不兼容) 或修复的 bug(关闭 Issue) 的链接。
- break changes
指明是否产生了破坏性修改，涉及break changes的改动必须指明该项，类似版本升级、接口参数减少、接口删除、迁移等
BREAKING CHANGE: isolate scope bindings definition has changed.
To migrate the code follow the example below:
Before:
scope: {
myAttr: 'attribute',
}
After:
scope: {
myAttr: '@',
}
The removed `inject` wasn't generaly useful for directives so there should be no code using it.
- affect issues
指明是否影响了某个问题。例如我们使用jira时，我们在commit message中可以填写其影响的JIRA_ID，若要开启该功能需要先打通jira与gitlab。参考文档
Closes #123, #245, #992
配置规则
配置规则文档：reference-rules
每条规则由名称和配置数组组成，如：name:[0, 'always', 72]，数组包含：
- Level，0-2：0表示禁用这条规则、1表示警告、2表示错误。
- Applicable，always|never：always表示使用规则，never表示不使用规则。
- Value：用于这条规则的值。
规则配置可以写为数组，或者是函数，或者异步函数，或者一个promise，只要函数最终返回的是配置数组就可以。
例子：
// 数组
"rules": {
"header-max-length": [0, "always", 72],
}
// 函数
"rules": {
"header-max-length": () => [0, "always", 72],
}
// 异步函数
"rules": {
"header-max-length": async () => [0, "always", 72],
}
// promise
"rules": {
"header-max-length": () => Promise.resolve([0, "always", 72]),
}
参考
https://mp.weixin.qq.com/s/ouJlkTFu8DEEb6HelqHiVA
https://commitlint.js.org/#/
网友评论