代码规范是软件开发领域经久不衰的话题,几乎所有工程师在开发过程中都会遇到或思考过这一问题。而随着前端应用的大型化和复杂化,越来越多的前端团队也开始重视代码规范。同样,前段时间,笔者所在的团队也开展了一波开源治理,而其中代码规范就占据了很重要的一项。接下来的几篇文章,将会对JS代码规范、CSS规范、Git提交规范、Git工作流规范以及文档规范进行详细的介绍~

系列文章:

  • 前端规范之JS代码规范(ESLint + Prettier)
  • 前端规范之CSS规范(Stylelint)
  • 前端规范之Git提交规范(Commitizen)
  • 前端规范之Gti工作流规范(Husky + Commitlint + Lint-staged)
  • 前端规范之文档规范

本文主要介绍了前端规范之Git工作流规范(Husky + Commitlint + Lint-staged),将会对Husky、Commitlint和Lint-staged的使用进行介绍,欢迎大家交流讨论~

1. 背景

在前面的几篇文章中,我们已经介绍了如何在项目中安装并配置ESLint、Prettier、Stylelint和Commitizen。有了这些工具,可以很好的帮助我们格式化代码并提示错误。

然而,有些同学可能会把ESLint、Stylelint或Commitizen提示的错误忽视不见,直接将代码提交到代码仓库中。这样做的话,那么其他同学在pull代码并diff代码时可能会出现大段代码标红,同时在进行CI时又可能因为代码风格或规范问题被打回重改。

那么,有没有一种方法,让大家在提交代码时需要确保本地的代码或Commit Message已经通过检查才能够push到代码仓库,从而更好的保障代码质量呢?接下来,将会介绍如何使用Husky + Commintlint + Lint-staged打造规范的Git检查工作流,确保我们的代码只有符合规范才能提交到代码仓库。

2. Husky

首先,先来介绍一下Husky的安装和相关配置。

2.1 什么是git hook

在介绍Husky之前,我们先来看什么是git hook,也就是常说的Git钩子。

和其它版本控制系统一样,Git能在特定的重要动作发生时触发自定义脚本。有两组这样的钩子:客户端的和服务器端的。 客户端钩子由诸如提交和合并这样的操作所调用,而服务器端钩子作用于诸如接收被推送的提交这样的联网操作。 你可以随心所欲地运用这些钩子。

其中,客户端钩子我们可能用的比较多,客户端钩子通常包括了提交工作流钩子、电子邮件工作流钩子和其它钩子。这些钩子通常存储在项目的.git/hooks目录下,我们需要关注的主要是提交工作流钩子。提交工作流钩子主要包括了以下四种:

  • pre-commit:该钩子在键入提交信息前运行。 它用于检查即将提交的快照。如果该钩子以非零值退出,Git 将放弃此次提交,你可以利用该钩子,来检查代码风格是否一致。
  • prepare-commit-msg:该钩子在启动提交信息编辑器之前,默认信息被创建之后运行。 它允许你编辑提交者所看到的默认信息。
  • commit-msg:该钩子接收一个参数,此参数存有当前提交信息的临时文件的路径。 如果该钩子脚本以非零值退出,Git 将放弃提交,因此,可以用来在提交通过前验证项目状态或提交信息。
  • post-commit:该钩子一般用于通知之类的事情。

在上面的钩子中,我们需要关注pre-commit和commit-msg钩子。

2.2 什么是husky

husky是常见的git hook工具,使用husky可以挂载Git钩子,当我们本地进行git commit或git push等操作前,能够执行其它一些操作,比如进行ESLint检查,如果不通过,就不允许commit或push。

2.3 安装husky

安装husky,可以使用npm进行安装。

npm install husky --save-dev

2.4 配置husky

安装好husky之后,还需要对husky进行配置。不同版本的husky配置方法有些不同,这里主要对4.3.8版本的配置进行介绍。

首先,我们需要先安装配置好ESLint或Stylelint,并且在package.json中加入以下代码。

"husky": {
"hooks": {
"pre-commit": "eslint src/**/*.{js,jsx,ts,tsx}",
}
}

接着,当我们执行git commit时,就会触发pre-commit钩子,并且执行对应命令,这里将会指定目录下的文件进行ESLint检查,如果ESLint检查不通过,是无法进行commit的。

如果ESLint检查通过,就可以正常进行commit。

在安装并配置好husky之后,如果发现在commit时不能触发pre-commit,可以试着重新安装husky,并且重启VSCode。

2.5 只使用husky的问题

使用husky虽然能够帮助我们在commit或push前执行一些指令,但是如果只使用husky,仍然存在下面这些问题:

  • 在某次提交时,我们只修改了某个文件,但是只使用husky会把所有的文件都运行一遍Lint检查,时间成本太高。此外,有些项目会在中途才加上husky,但是在commit时husky也会对其它未修改的历史代码进行检查,可能会一下子报了很多错误,这个时候我们更希望只对当前修改过的文件进行检查,而不是对项目中的代码都进行检查。
  • husky的钩子只能执行一个指令,但是有时候我们希望能够在git commit之前执行多个指令,比如执行ESLint、Stylelint或Commitlint等操作。

为了解决上面的问题,就需要结合Lint-staged一起使用。

3. Lint-staged

接下来,将会对Lint-staged的安装和配置进行介绍。

3.1 什么是Lint-staged

Lint-staged可以在git staged阶段的文件上执行Linters,简单说就是当我们运行ESlint或Stylelint命令时,可以通过设置指定只检查我们通过git add添加到暂存区的文件,可以避免我们每次检查都把整个项目的代码都检查一遍,从而提高效率。

其次,Lint-staged允许指定不同类型后缀文件执行不同指令的操作,并且可以按步骤再额外执行一些其它shell指令。

3.2 安装Lint-staged

安装Lint-staged,可以使用npm进行安装。

npm install lint-staged --save-dev

3.3 配置Lint-staged

安装好了Lint-staged之后,就需要配置Lint-staged。我们可以在package.json中加入以下代码,这里需要先安装配置好husky,ESLint和Stylelint。

"husky": {
"hooks": {
"pre-commit": "lint-staged",
}
},
"lint-staged": {
"*.vue": [
"eslint --fix",
"stylelint --fix",
"git add"
],
"*.{js,jsx,ts,tsx}": [
"eslint --fix",
"git add"
],
"*.{htm,html,css,sss,less,scss,sass}": [
"stylelint --fix",
"git add"
]
}

当我们执行git commit时,就会触发husky的pre-commit钩子,调用lint-staged命令。而lint-staged包含了对*.vue,*.{js,jsx,ts,tsx},*.{htm,html,css,sss,less,scss,sass}类型文件的操作。以*.vue为例,当匹配到后缀名为.vue的文件时,就会分别执行以下操作:

  • 首先会执行eslint --fix命令,对.vue文件执行ESLint检查,并且自动修复一些JS格式问题
  • 接着会执行stylelint --fix命令,对.vue文件的CSS执行Stylelint检查,并且自动修复一些CSS格式问题
  • 最后,若前面的指令都执行通过,那么将通过git add命令将文件重新加入到本地的git commit中,如果没有执行通过,那么将不能commit

4. Commitlint

除了在commit前对JS和CSS执行ESLint和Stylelint检查之外,也可以对Commit Message进行检查。接下来,将会介绍Commitlint的安装和配置方法。

4.1 什么是Commitlint

在使用Git提交代码时,通常都需要填写提交说明,也就是Commit Message。在前面的文章中,已经介绍了如何使用Commitizen或可视化工具编写符合规范的Commit Message。然而有些同学可能还是会使用git commit方式提交一些不符合规范的Commit Message。为了禁止不符合规范的Commit Message的提交,我们就需要采用一些工具,只有当开发者编写了符合规范的Commit Message才能够进行commit。而Commitlint就是这样一种工具,通过结合husky一起使用,可以在开发者进行commit前就对Commit Message进行检查,只有符合规范,才能够进行commit。

4.2 安装Commitlint

使用npm安装Commitlint相关依赖包。

npm install @commitlint/cli @commitlint/config-conventional --save-dev

4.3 配置Commitlint

安装好Commitlint之后,就需要配置Commitlint,可以在根目录创建commitlint.config.js文件进行配置。

在comminlint.config.js中加入以下代码,表示使用config-conventional规范对提交说明进行检查。具体的规范配置可以查看:https://github.com/conventional-changelog/commitlint

module.exports = { extends: ['@commitlint/config-conventional'] };

接下来,需要在package.json中加入commit-msg钩子。

"husky": {
"hooks": {
"commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
}
}

配置好了之后,当我们进行git commit时,就会触发commit-msg钩子,执行commintlint命令,并且读取commitlint.config.js中的规则对我们的提交说明进行检查,如果校验不通过,将不能提交。

5. Git检查工作流

在介绍完Husky,Commitlint和Lint-staged之后,接下来,我们就可以将这几个工具结合起来,打造完整的Git检查工作流。下面给出了一份示例代码,其中,该项目采用了Vue-cli进行构建,下面是该项目对应的package.json文件。

{
"name": "test",
"version": "0.1.0",
"private": true,
"scripts": {
"serve": "vue-cli-service serve",
"build": "vue-cli-service build",
"lint": "vue-cli-service lint",
},
"dependencies": {
"core-js": "^3.6.5",
"vue": "^2.6.11",
"vue-router": "^3.2.0",
"vuex": "^3.4.0"
},
"devDependencies": {
"@commitlint/cli": "^12.1.4",
"@commitlint/config-conventional": "^12.1.4","@vue/cli-plugin-babel": "^4.5.0",
"@vue/cli-plugin-eslint": "^4.5.0",
"@vue/cli-service": "^4.5.0",
"@vue/eslint-config-prettier": "^6.0.0",
"babel-eslint": "^10.1.0",
"eslint": "^6.7.2",
"eslint-plugin-prettier": "^3.3.1",
"eslint-plugin-vue": "^6.2.2",
"husky": "^4.3.8",
"less": "^3.0.4",
"less-loader": "^5.0.0",
"lint-staged": "^11.0.0",
"prettier": "^2.2.1",
"stylelint": "^13.13.1",
"stylelint-config-prettier": "^8.0.2","stylelint-config-standard": "^22.0.0",
"stylelint-order": "^4.1.0",
"stylelint-webpack-plugin": "^2.2.2",
"vue-template-compiler": "^2.6.11"
},
"husky": {
"hooks": {
"pre-commit": "lint-staged",
"commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
}
},
"lint-staged": {
"*.vue": [
"vue-cli-service lint",
"stylelint --fix",
"git add"
],
"*.{js,jsx,ts,tsx}": [
"vue-cli-service lint"
"git add"
],
"*.{htm,html,css,sss,less,scss,saas}":[
"stylelint --fix"
"git add"
]
}
}

配置好package.json之后,当我们进行git commit提交时,首先将会触发pre-commit钩子,调用lint-staged命令,并且会对不同后缀的文件执行不同的检查。接着,还将会触发commit-msg钩子,调用commitlint对我们的提交说明进行检查。如果其中一个无法通过检查,将无法提交。

当校验通过时,就可以放心的将代码提交到代码仓库中,而不用再担心代码风格等问题啦~

前端规范之Git工作流规范(Husky + Comminilint + Lint-staged)的更多相关文章

  1. 前端规范之Git提交规范(Commitizen)

    代码规范是软件开发领域经久不衰的话题,几乎所有工程师在开发过程中都会遇到或思考过这一问题.而随着前端应用的大型化和复杂化,越来越多的前端团队也开始重视代码规范.同样,前段时间,笔者所在的团队也开展了一 ...

  2. 前端规范之JS代码规范(ESLint + Prettier)

    代码规范是软件开发领域经久不衰的话题,几乎所有工程师在开发过程中都会遇到或思考过这一问题.而随着前端应用的大型化和复杂化,越来越多的前端团队也开始重视代码规范.同样,前段时间,笔者所在的团队也开展了一 ...

  3. Git commit message和工作流规范

    目的 统一团队Git commit日志标准,便于后续代码review,版本发布以及日志自动化生成等等. 统一团队的Git工作流,包括分支使用.tag规范.issue等 Git commit日志参考案例 ...

  4. 产品管理开发之Git工作流和分支规范推荐

    前言 无论是开源项目还是内部项目,使用Git都是大势所趋,尤其是在产品管理这块,使用Git大大提高了开发效率和产品的交付频率.本篇,针对Git的工作流和分支使用,进行了一些推荐. 目录 1     产 ...

  5. 最全面的Git 使用规范装逼指南[转载]

    <!DOCTYPE html> <script type="text/javascript"> window.logs = { pagetime: {} } ...

  6. PHP 代码规范、流程规范、git规范

    1. 命名规范 (1).变量命名规范 1.变量使用驼峰命名法 禁止使用拼音或者拼音加数字 2.变量也应具有描述性,杜绝一切拼音.或拼音英文混杂的命名方式 3.变量包数字.字母和下划线字符,不允许使用其 ...

  7. git 使用规范

    git使用资料: https://github.com/peak-c/my-git 公司内部使用开发规范: 一. 代码库介绍 个人开发库(git@gitlab.adrd.sohuno.com:sper ...

  8. 开发中的你的Git提交规范吗?

    1. 前言 目前大部分公司都在使用Git作为版本控制,每个程序员每天都要进行代码的提交.很多开发者也包括我自己,有时候赶时间或者图省事,就这么提交: git commit -m "修改bug ...

  9. Git提交代码规范 而且规范的Git提交历史,还可以直接生成项目发版的CHANGELOG(semantic-release)

    Git提交代码规范 - 木之子梦之蝶 - 博客园 https://www.cnblogs.com/liumengdie/p/7885210.html Commit message 的格式 Git 每次 ...

随机推荐

  1. 定位API的原理

    参考:0Day 安全 所有的win_32程序都会加载ntdll.dll和kerner32.dll这两个最基础的动态链接库.如果想要在win_32平台下定位kernel32.dll中的API地址 1,首 ...

  2. web项目中的浏览器行为和服务器行为

    package day10.think_about_path; import java.io.IOException; import javax.servlet.ServletException; i ...

  3. 刷题-力扣-63. 不同路径 II

    63. 不同路径 II 题目链接 来源:力扣(LeetCode) 链接:https://leetcode-cn.com/problems/unique-paths-ii/ 著作权归领扣网络所有.商业转 ...

  4. 1 分钟快速使用 Docker 上手最新版 Sentry-CLI - 创建一个版本

    我们可以使用官方 sentry-cli 工具操作 Sentry API,从而来为你的项目管理一些数据.它主要用于管理 iOS.Android 的调试信息文件,以及其他平台的版本(release)和源代 ...

  5. 多源最短路径,一文搞懂Floyd算法

    前言 在图论中,在寻路最短路径中除了Dijkstra算法以外,还有Floyd算法也是非常经典,然而两种算法还是有区别的,Floyd主要计算多源最短路径. 在单源正权值最短路径,我们会用Dijkstra ...

  6. VMware ESXi 7.0 U2 SLIC & Unlocker USB 网卡驱动集成镜像 202109更新

    2021.08.31 更新:集成 "vmkusb-nic-fling"."net-community" 和 "nvme-community" ...

  7. Linux下sed找出IP中第四位

    ip addr|sed -n '9p'|egrep '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}'|sed -nr 's#^.*inet (.*) b ...

  8. 作用域 作用域链 闭包 思想 JS/C++比较

    首先,我说的比较是指JS中这种思想/实现方式与C++编译原理中思想/实现方式的比较 参考链接:(比较易懂的介绍,我主要写个人理解) 作用域链: http://www.cnblogs.com/dolph ...

  9. 稚晖君-最小linux服务器运行 nginx + netcore

    华为天才少年, B站科技大神,稚晖君(自称野生钢铁侠),多少科技爱好者拜服在他的全方位技术栈 今天我们就去入手一个他的量产产品 号称最小linux电脑 的"夸克" 到手之后,我们马 ...

  10. TCP超时重传、序列号、滑动窗口简介

    文章目录 12 TCP:传输控制协议(初步) 12.1 引言 12.1.1 ARQ和重传 12.1.2 分组窗口和滑动窗口 12.1.3 变量窗口:流量控制和拥塞控制 12.1.4 变量窗口:设置重传 ...