本文的目的是为了给想要快速搭建一套业内流行的 angular 团队代码提交规范 (不是 angular 团队编写代码的规范) 的小伙伴们提供一个简单清晰直白的教程. 文章的内容不会深究每个环节的细节, 但是会用通俗的话语让需要的小伙伴们了解每个环节的含义和作用, 从而能做到从 0 到 1 的搭建起代码提交的工作流.
第一步, 格式化 commit message
commit message 的重要性我就不在这强调了, 我们常规提交代码都是通过 Git commit -m "xxx" 附上一句话来描述此次代码的改动, 这样的方式对于一些影响范围大或者 broken 式的改动来说太过于简单随意. 每个人都有自己习惯的提交代码方式, 所以我们需要借助一个工具来生成符合规范的 commit message 并约束提交的人.
https://github.com/commitizen/cz-cli 是一个格式化 commit message 的工具, 可以约束提交者按照制定的规范一步一步的填写 commit message.
局部安装
NPM i -D commitizen
配置:
package.JSON 中:
- "script": {
- ...,
- "commit": "git-cz",
- }
这样我们就可以借助 commitizen 提供的 Git-cz, 用 NPM run commit 命令来替代 Git commit 命令.
第二步, 采用 angular 团队提交的规范
我们已经把可以生成指定 commit message 的工具 commitizen 安装好了, 接下来要做的就是为 commitizen 制定一套填写规范.
is a commitizen adapter for the angular preset of conventional-changelog (一套适合 commitizen 的 angular 团队规范的 preset). 目前采用比较广泛, 那我们就直接给 commitizen 引用这套规范了.
局部安装
NPM i -D cz-conventional-changelog
配置:
package.JSON 中:
- "config": {
- "commitizen": {
- "path": "node_modules/cz-conventional-changelog"
- }
- }
安装配置好以后, 执行 NPM run commit 就会出现如下引导式填写:
第三步, 校验 commit message
虽然之前两步已经约束了一套代码提交规范, 但是还是有人不按照规范提交代码怎么办呢? 这个时候就需要来帮助我们校验 commit message, 拒绝不符合规范的 commit message.
与 eslint 类似, commitlint 也需要一份校验的配置. 别着急, 这里有一份与 cz-conventional-changelog 规范 (angular 团队规范) 配套的校验配置 @commitlint/config-conventional 来帮助我们检验 commit message 的合规性.
局部安装
NPM i -D @commitlint/config-conventional @commitlint/cli
配置
安装完成以后, 同时需要在项目根目录下创建配置文件 commit.config.JS 或者. commitlintrc.JS 并写入:
- module.exports = {
- extends: [
- '@commitlint/config-conventional'
- ]
- }
或者在 package.JSON 中写入:
- "commitlint": {
- "extends": [
- "@commitlint/config-conventional"
- ]
- },
commitlint 就可以运用 config-conventional 这套校验配置.
第三步, 配置校验时机
到了第三步我们的代码提交约束规范已经基本成型了, 最后一步要做的就是配置触发 commit message 校验的时机.
校验 commit message 的最佳姿势是 Git hook 和 https://github.com/typicode/husky 的结合.
husky(哈士奇)是个什么东西呢? 简单来说就是个能让你在每个 Git 钩子中配置相应行为的一个工具.
局部安装
NPM install husky --save-dev
配置
安装完成以后, 同时需要在项目根目录下创建配置文件. huskyrc 或者. huskyrc.JS 文件并写入:
- {
- "husky": {
- "hooks": {
- ...,
- "commit-msg": "commitlint -e $GIT_PARAMS"
- }
- }
- }
或者在 package.JSON 中写入:
- "husky": {
- "hooks": {
- ...,
- "commit-msg": "commitlint -e $GIT_PARAMS"
- }
- }
在 Git commit-msg 这个钩子中会触发 commitlint 的操作.
第四步, 自动化代码检查
其实前三步已经打造好了基于 angular 团队代码提交规范的工作流了, 但是如果我们在提交代码的时候不仅仅需要校验 commit message 的规范性还要校验代码的正确性呢?
https://github.com/okonet/lint-staged 可以让你每次只对你此次提交所在暂存区的文件 (Git add 后的文件) 进行一系列的检查, 修复, 格式化操等作.
局部安装
NPM install -D lint-staged
配置
安装完成以后, 同时需要在项目根目录下创建配置文件. lintstagedrc 并写入:
- {
- "*.{js,vue}": ["eslint --fix", "git add"]
- }
或者在 package.JSON 中写入:
- "lint-staged": {
- "*.{js,vue}": ["eslint --fix", "git add"]
- }
在第三步创建的 husky 配置文件进行补充:
- "husky": {
- "hooks": {
- "pre-commit": "lint-staged",
- "commit-msg": "commitlint -e $GIT_PARAMS"
- }
- }
在 pre-commit 这个钩子中, lint-staged 会执行. lintstagedrc 配置的操作(列出来的配置的意思是对本次提交的 JS 或者 vue 文件进行 eslint 检查并修复, 并且把修复过后的文件再重新提交到暂存区).
第五步, 生成 CHANGELOG
可以自动根据 commit message 生成 CHANGELOG.
局部安装
NPM install conventional-changelog-cli --save-dev
配置
- "scripts": {
- ...,
- "version": "conventional-changelog -p angular -i CHANGELOG.md -s -r 0 && git add CHANGELOG.md"
- }
执行 NPM run version 就能生成 CHANGELOG.md 文件. 因为 CHANGELOG 适用于有版本迭代的工具开发 (不适用于业务代码), 来记录每个版本的改动, 所以需要先使用 NPM version [version] 更改版本号, 再生成 CHANGELOG, 这样生成的 CHANGELOG 只对应着你这次修改的版本.
最后
一个完整的基于 angular 团队代码提交规范的工作流已经打造完成, 如果有不适应 angular 这套规范的话也可以自定义一套规范, 这里就不再赘述了. 也有可能有的小伙伴觉得这么写 commit 很麻烦, 但是一个好的提交规范习惯有助于整个团队在项目中高效率的开发, 所以赶紧在自己项目中用起来吧!
来源: https://juejin.im/post/5c85bdde5188257dfa07da6b