小编点评

**commitlint** 是一个用于检查前端提交信息的工具，它可以用于确保提交信息的格式符合规范，并帮助开发者更轻松地实现代码版本控制。 **基本用法：** 1. 安装 `commitlint` 和 `cz-customizable` 工具： ```bash npm install commitizen cz-customizable ``` 2. 配置 `cz-customizable`： ```json { "commitizen": { "path": "node_modules/cz-customizable" }, "cz-customizable": { "config": "config/path/to/my/config.js" } } ``` 3. 使用 `git cz` 命令提交代码： ```bash git cz -m "My commit message" ``` **配置 options：** `commitlint` 可以配置一些选项，以定制代码版本控制的 behavior，例如： - `header-max-length`：指定 commit message 的最大长度。 - `scope`：指定修改代码的范围，例如 `body`、`footer` 或 `both`。 - `skipQuestions`：指定跳过的步骤，例如详细描述。 - `subjectLimit`：指定摘要的长度限制。 **其他资源：** - `commitlint 文档：` ``` $ npx commitlint --version ``` - `cz-customizable 文档：` ``` $ npm install cz-customizable $ npx cz-customizable ```

正文

前言

通过工具规范git提交信息也是工程化的一部分，在前端领域有一些工具为我们提供了相关功能，在这里做一下使用总结。

commitlint

1. commitlint是什么？
   就像eslint用来检查js代码是否标准，commitlint用来检查提交信息是否满足固定格式的工具。
   同样，commitlint提供了一些规则供我们配置。

2. commitlint怎么用？
   和eslint一样，commitlint提供了相应的api供我们调用、或者和其他工具集成
   安装：npm install -g @commitlint/cli @commitlint/config-conventional 其中@commitlint/config-conventional是常用的插件。 commitlint常用命令：

   • commitlint -e 命令就可以检查.git/COMMIT_EDITMSG里面的commit message是否符合格式；
   • commitlint -e ./aaa 命令就可以检查文件./aaa里面内容是否符合格式；
   • commitlint -E HUSKY_GIT_PARAMS 读取环境变量HUSKY_GIT_PARAMS对应的文件的内容，默是.git/COMMIT_EDITMSG

3. 配置文件 commitlint.config.js/.commitlintrc.js

   类似于.eslintrc.js文件，用来配置commitlint规则。extends字段类似于eslint的extends

   module.exports = {
     extends: ['@commitlint/config-conventional'],
     rules: {
   	'header-max-length': [2, 'always', 60],
     },
   };
   

commitizen

1. commitizen是什么？

   正常git commit 我们可以写出符合commitlint的提交信息，但是如果有命令行提示我们一步步的写就更方便了，于是出现了commitizen就是一个这样的工具。

2. commitizen怎么用？

   • npm install commitizen 之后使用 git cz 来替代 git commit 提交信息。
   • npm install cz-customizable

   cz-customizable 是可自定义的Commitizen插件，

   commitizen中有个 Commitizen friendly的概念，如果是Commitizen-friendly ,执行git cz会进入交互式操作；如果不是Commitizen-friendly就会和普通git commit一样。一般项目在没有安装相关插件的情况下不是Commitizen-friendly, 要做到Commitizen-friendly需要adapter，比如：cz-customizable 或者cz-conventional-changelog 。cz-customizable 用的更多一些。

3. 配置cz-customizable

   指定commitizen用哪个adapter：

   // package.json
   "config": {
   	"commitizen": { 
   		"path": "node_modules/cz-customizable"
   	},
   	"cz-customizable": {
   		"config": "config/path/to/my/config.js"
   	}
   }
   

   创建.cz-config.js自定义提交规则。

    - types: 描述修改的性质是什么，是bugfix还是feat，在这里进行定义。
    - scopes: 定义之后，我们就可以通过上下键去选择 scope
    - scopeOverrides: 针对每一个type去定义scope
    - allowBreakingChanges: 设置为 ['feat', 'fix']，只有我们type选择了 feat 或者是 fix，才会询问我们 breaking message.
    - allowCustomScopes: 设置为 true，在 scope 选择的时候，会有 empty 和 custom 可以选择，顾名思义，选择 empty 表示 scope 缺省，如果选择 custom，则可以自己输入信息
    - skipQuestions: 指定跳过哪些步骤，例如跳过我们刚刚说的详细描述，设置其为 scope: ['body']，假设我们的项目也不会涉及到关联 issue，我们可以设置其为 scope: ['body', 'footer']
    - subjectLimit: 描述的长度限制
   

   cz-customizable 会首先在项目根目录下寻找: .cz-config.js 或 .config/cz-config.js，如果找不到，会去主目录寻找。我们也可以在 package.json 中手动去指定配置文件的路径

总结

可以使用commitlint做提交信息的校验， 也可以使用commitizen简化提交的负担，还可以使用husky将这些约束放到提交钩子里，这些都是在本地做的校验，开发者其实是可以跳过这些校验和约束的，那么如果要做更严格的约束就需要在远程git服务器上增加校验处理。