Guia de uso de mensagens de commit

prefácio

Toda vez que o Git envia código, ele deve escrever uma mensagem de commit (descrição do commit). Para uma mensagem de commit padrão, ele pode nos trazer:

Fornecer mais informações históricas para navegação rápida;
Alguns commits (como alterações de documentos) podem ser filtrados para facilitar a busca rápida de informações;
O documento de atualização de versão pode ser gerado gerando diretamente o arquivo de log de alterações de acordo com o commit.

Portanto, as especificações desempenham um papel importante git commit na melhoria da git log legibilidade, controle de versão e changeloggeração de .

Vamos aprender a usá-lo a partir do formato da mensagem Commit e como padronizar e restringir o commit.

Formato da mensagem de confirmação

A mensagem de confirmação consiste em três partes: Cabeçalho, Corpo e Rodapé. A estrutura é a seguinte:

<类型>([可选的作用域]): <描述> - header
// 空一格
[可选的正文] - body
// 空一格
[可选的脚注] - footer
复制代码

Entre eles, Header é obrigatório, e Body e Footer podem ser omitidos. Normalmente só precisamos escrever Header.

A seção Cabeçalho tem apenas uma linha e inclui três campos: type(obrigatório), scope(opcional) e subject(obrigatório).

1. tipo: É
typeusado para descrever a categoria de commit, e os 7 sinais a seguir são geralmente permitidos.

feat: novo recurso (recurso)
corrigir: corrigir erros
docs: Documentação
style: format (alterações que não afetam a execução do código)
refatoração: refatoração (ou seja, não é um novo recurso, nem uma mudança de código que corrige um bug)
teste: adicionar teste
chore: mudanças no processo de construção ou ferramentas auxiliares

E typeserá usado para gerar changlog, se typefor feate fix, o commit definitivamente aparecerá no log de alterações.

2、scope：
scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。

3、subject：
subject是 commit 目的的简短描述，不超过50个字符。

Commit 前的代码校验

在执行git commit之前，需要进行代码规则检查能够确保进入 git 库的代码都是符合代码规则的。我们可以借助两个工具包来实现：lint-staged 和 husky。

lint-staged：由于整个项目上运行 lint 速度会很慢，lint-staged 能够让 lint 只检测暂存区的文件；
husky：可以让我们在项目中方便添加 git hooks。

1、安装：

npm install lint-staged husky@^4.3.8 -D
复制代码

注意，上面我们指定了 husky 版本，如果不指定版本号，将安装最新版本 husky（6.0.0以上），配置方式会有所不同，具体步骤可参考文档配置。

2、在 package.json 中配置：

"scripts": {
  "lint": "eslint src --ext .js,.jsx,.ts,.tsx"
},
"husky": {
  "hooks": {
    "pre-commit": "lint-staged"
  }
},
"lint-staged": {
  "src/**/*.{js,json,css,scss,ts,tsx,md}": [
    "eslint"
  ]
},
复制代码

3、使用：
首先确保项目内配置了 ESLint，参考配置可以看这里。我们在 src/index.js 编写一个不规范的代码，执行：

git add .
git commit -m 'feat: 配置 commit lint code'
复制代码

当变更文件内的代码校验不合格时，会中断提交。

规范 Commit message

Commitizen 是一个撰写合格 Commit message 的工具，提供了一组 Header.type 可选列表来规范 commit message。

1、安装：

npm install commitizen cz-conventional-changelog -D
复制代码

2、在 package.json 内进行配置（使用业界 Angular 的 Commit message 格式）：

"config":{
  "commitizen":{
    "path":"./node_modules/cz-conventional-changelog"
  }
},
复制代码

3、添加执行 commit 脚本：

"scripts": {
  "commit": "git-cz",
}
复制代码

注意这里，凡是用到 git commit 命令，一律改为使用 git-cz。这时，就会出现选项，用来生成符合格式的 Commit message。

4、执行：

npm run commit
复制代码

生成 CHANGELOG

当我们有了规范的 Commit message 后，就可以根据它们自动生成 CHANGELOG.md。

1、安装：

npm install conventional-changelog-cli -D
复制代码

2、在 package.json 中配置执行脚本：

"scripts": {
  "changelog": "conventional-changelog -p angular -i CHANGELOG.md -s",
}
复制代码

注意：上面命令不会覆盖以前的 Change log，只会在 CHANGELOG.md 的头部加上自从上次发布以来的变动。

如果你想生成一个完整的 Change log 到 CHANGELOG.md 文件，需要运行下面的命令：

"scripts": {
  "changelog": "conventional-changelog -p angular -i CHANGELOG.md -s -r 0",
}
复制代码

3、执行：

npm run changelog
复制代码

最后

感谢阅读。

借鉴于：阮一峰：Commit message 和 Change log 编写指南