Guía de uso de mensajes de confirmación

prefacio

Cada vez que Git envía código, debe escribir un mensaje de confirmación (descripción de la confirmación).Para un mensaje de confirmación estándar, puede traernos:

Proporcione más información histórica para una navegación rápida;
Algunas confirmaciones (como los cambios de documentos) se pueden filtrar para facilitar la búsqueda rápida de información;
El documento de actualización de la versión se puede generar generando directamente el archivo de registro de cambios de acuerdo con la confirmación.

Por lo tanto, las especificaciones juegan un papel importante git commit en la mejora de la git log legibilidad, el control de versiones y changelogla generación .

Aprendamos a usarlo desde el formato del mensaje de confirmación y cómo estandarizar y restringir la confirmación.

Confirmar formato de mensaje

El mensaje de confirmación consta de tres partes: encabezado, cuerpo y pie de página. La estructura es la siguiente:

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

Entre ellos, se requiere el encabezado y se pueden omitir el cuerpo y el pie de página. Por lo general, solo necesitamos escribir Header.

La sección Encabezado tiene una sola línea e incluye tres campos: type(obligatorio), scope(opcional) y subject(obligatorio).

1. tipo:
typese utiliza para describir la categoría de compromiso, y generalmente se permiten los siguientes 7 signos.

hazaña: nueva característica (característica)
corregir: corregir errores
documentos: Documentación
estilo: formato (cambios que no afectan la ejecución del código)
refactor: refactorización (es decir, no es una característica nueva ni un cambio de código que solucione un error)
prueba: añadir prueba
tarea: cambios en el proceso de construcción o herramientas auxiliares

Y typese usará para generar changlog, si typees featy fix, la confirmación definitivamente aparecerá en el registro de cambios.

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 编写指南