git commit message规范工具

管理工具

commitlint
commitizen

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格式

():  
// 空一行

// 空一行

分别对应 Commit message 的三个部分:Header,Body 和 Footer.

注意冒号后面有空格

使用

执行git cz进入interactive模式,根据提示依次填写

1.Select the type of change that you're committing 选择改动类型 ()

2.What is the scope of this change (e.g. component or file name)? 填写改动范围 ()

3.Write a short, imperative tense description of the change: 写一个精简的描述 ()

4.Provide a longer description of the change: (press enter to skip) 对于改动写一段长描述 ()

5.Are there any breaking changes? (y/n) 是破坏性修改吗?默认n (
) 6.Does this change affect any openreve issues? (y/n) 改动修复了哪个问题?默认n (
)

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/#/

你可能感兴趣的:(git commit message规范工具)