阅读 1471

前端工程化(2):快速搭建基于angular团队代码提交规范的工作流

本文的目的是为了给想要快速搭建一套业内流行的angular团队代码提交规范(不是angular团队编写代码的规范)的小伙伴们提供一个简单清晰直白的教程。文章的内容不会深究每个环节的细节,但是会用通俗的话语让需要的小伙伴们了解每个环节的含义和作用,从而能做到从0到1的搭建起代码提交的工作流。

1. 格式化 commit message

commit message的重要性我就不在这强调了,我们常规提交代码都是通过git commit -m "xxx"附上一句话来描述此次代码的改动,这样的方式对于一些影响范围大或者broken式的改动来说太过于简单随意。每个人都有自己习惯的提交代码方式,所以我们需要借助一个工具来生成符合规范的commit message并约束提交的人。

commitizen是一个格式化commit message的工具,可以约束提交者按照制定的规范一步一步的填写commit message

局部安装

npm i -D commitizen

配置:

package.json中写入:

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

这样我们就可以借助commitizen提供的git-cz,用npm run commit命令来替代git commit命令。

2. 采用 angular 团队代码提交规范

我们已经把可以生成指定commit message的工具commitizen安装好了,接下来要做的就是为commitizen制定一套填写规范。

cz-conventional-changelog is a commitizen adapter for the angular preset of conventional-changelog (一套适用于commitizenangular团队规范)。目前采用比较广泛,那我们就直接给commitizen引用这套规范了。

局部安装

npm i -D cz-conventional-changelog

配置:

package.json中写入:

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

安装配置好以后,执行npm run commit就会出现如下引导式填写:

3. 校验 commit message

虽然之前两步已经约束了一套代码提交规范,但是还是有人不按照规范提交代码怎么办呢?这个时候就需要commitlint来帮助我们校验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这套校验配置。

4. 配置校验时机

到了第三步我们的代码提交约束规范已经基本成型了,最后一步要做的就是配置触发commit message校验的时机。

校验commit message的最佳姿势是git hookhusky的结合。

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的操作。

5. 自动化代码检查

经过前三步已经打造好了基于angular团队代码提交规范的工作流了,但是如果我们还想在校验commit message的规范性的同时,校验此次提交代码的正确性呢?

借助 lint-staged 可以让你每次只对你此次提交所在暂存区的文件(git add后的文件)进行一系列的检查、修复、格式化操等作。

局部安装

npm install -D lint-staged

配置

安装完成以后,同时需要在项目根目录下创建配置文件.lintstagedrc并写入:

{
  "*.{js,vue}": [
    "eslint --fix",
    "git add"
  ],
  "*.{html,vue,css,sass,scss}": [
    "stylelint --fix",
    "git add"
  ]
}
复制代码

或者在package.json中写入:

"lint-staged": {
    "*.{js,vue}": [
    "eslint --fix",
    "git add"
  ],
  "*.{html,vue,css,sass,scss}": [
    "stylelint --fix",
    "git add"
  ]
}
复制代码

在第三步创建的husky配置文件进行补充:

"husky": {
    "hooks": {
        "pre-commit": "lint-staged",
        "commit-msg": "commitlint -e $GIT_PARAMS"
    }
}
复制代码

pre-commit这个钩子中,lint-staged会执行.lintstagedrc配置的操作(列出来的配置的意思是对本次提交的js或者vue文件进行eslint检查并修复,并且把修复过后的文件再重新提交到暂存区)。

6. 版本发布

对于每次项目新版本的发布,我们需要更新相应的版本号并记录其中的改变。可以借助 standard-version 工具,来替代npm run version,并自动生成CHANGELOG

局部安装

npm install standard-version --save-dev
复制代码

配置

"scripts": {
    "release": "standard-version",
    ...
 }
复制代码

执行npm run release指令实际执行了五个动作:

  1. 修改package.json中的版本号
  2. 修改package-lock.json中的版本号
  3. 生成CHANGELOG.md文件
  4. 提交package.jsonpackage-lock.jsonCHANGELOG.md文件
  5. 给这次提交记录打上tag

如果发布的是首个版本,则可以运行如下指令:

npm run release -- --firse-release
复制代码

如果需要发布预发布版本,则可以使用--prerelease/-p标志来添加预发布版本号:

# 当前版本为 1.0.0
npm run release -- --prerelease  # 版本为 1.0.1-0
npm run release -- --prerelease beta  # 版本为 1.0.1-beta.1
复制代码

如果是正常的版本迭代,则可以使用--release-as/-r标志来指定版本:

# 当前版本为 1.0.0
npm run release -- --release-as patch  # 版本为 1.0.1,npm run release默认行为
npm run release -- --release-as minor  # 版本为 1.1.0
npm run release -- --release-as major  # 版本为 2.0.0
npm run release -- --release-as 2.0.1  # 版本为 2.0.1
npm run release -- --release-as 2.0.1-alpha.0  # 版本为 2.0.1-alpha.0
复制代码

一般项目要上线新版本的时候,需要把release分支合到master,合完分支以后执行npm run release指令给这次发布打上tag并记录修改是一个良好的维护版本迭代的好习惯。

最后

一个完整的基于angular团队代码提交规范的工作流已经打造完成,如果有不适应angular这套规范的话也可以自定义一套规范,这里就不再赘述了。当然,有的小伙伴觉得这么写commit很麻烦,但是一个好的提交规范习惯有助于整个团队在项目中高效率的开发,所以赶紧在自己项目中用起来吧!

关注下面的标签,发现更多相似文章
评论