【工具】Git Hook

失踪人口终于回来了

因为换了一个公司，发现在这里有太多东西学了，而且技术大牛特别多，仿佛从原始时代进入了工业时代，所以一直在埋头学习，就好久没有更新文章了。

后面打算把这里学到的所有东西都写成文章，变成自己的哈哈哈

但是还是先把之前的知识给总结完，温故而知新，我写的文章，自己忘了都会拿出来看的，果然没有白费我花这么精力去写

废话不多说，继续总结

作为一个合格的前端，项目中的自动化检查和自动化测试是必须要学会的

之前这个东西我是蛮抵触的，虽然有接触过，但是总觉得这个东西很麻烦和 难

所以也就草草学会用一下，当然，现在也早已经忘光了但是这样不行的啊，所以我才立志把这些东西逐一突破，并且运用在项目中，并且现在大公司每个项目都必须使用到这个的，所以不熟悉是不行的

今天我打算分几个问题去彻底了解 Git Hook

1、什么是 git hook？

2、有什么用？

3、怎么简单用？

4、怎么配合项目使用？

5、怎么使用更加方便？

Git Hook是什么

git hook 是在 git 发生某些操作时会触发的脚本

脚本在哪里？

当你使用 git init 初始化时，就会生成

你可以在钩子的文件夹中有很多文件，没错，这些就是钩子触发的脚本

有什么钩子

钩子分为两种，客户端钩子 和 服务端钩子

客户端钩子，会在本地提交和合并的使用调用，比如 上面出现的脚本文件，

pre-commit.sample 在 commit 时被调用pre-push.sample 在 push 时被调用

服务端钩子，则是在接收被推送的提交这样的联网操作时被调用，比如 pre-receive.sample 在 接收推送时被调用

你可能在想，为什么要分两种钩子？看完下面 git hook 作用再揭晓

这些文件都是什么？

打开这些文件，发现他们就是 shell 脚本

我们通过 shell 命令来操作和控制操作系统shell 命令包含有 ls，cd 等。总的来说，shell 就是一个命令解释器接收用户输入的 shell 命令来执行相应的操作。而如果我们想一次性执行大量 shell 命令 然后把 这些命令集中放到一个文件中那么这个文件就叫做 shell 脚本

这些脚本你可以使用 Python 去编写他们

你可以看到，这些文件都是以 .sample 结尾的，如果你想 git 在 发生特定操作时会调用这些脚本，你需要把 .sample 这个后缀给去掉

git hook 有什么用？

当我们知道，git hook 会在特定操作发生时调用某些脚本之后，所以我们就可以在脚本上面做文章了比如我们会弄一个脚本，在提交之前，把我们项目中的代码给 检查一遍，看他们是否规范，如果不规范就报错，不让你提交

或者 提交之前 跑一遍测试，保证代码的健壮性，不通过测试也不让提交。

在团队的项目合作中，这是非常有必要的，因为大家的水平参差不齐，为了在保证项目质量的情况下，这一步是必须的。

强制规范你的代码，不然让你轻易提交一堆又有 bug 又乱七八糟的代码，这 TM 无疑是 自杀

但是，有一种方法，可以跳过本次的检查，也就是跳过本地钩子的触发！

那就是

git commit --no-verify

卧槽，这特么就让你这么容易轻松逃过了？？

所以！我们才有了服务端钩子！！就算你逃得过本地检查，也逃不过远程仓库的检查，哈哈哈

但是记得这个跳过也是非常有必要的啊，因为并不是所有提交都必须要检查的，所以需要记住这个东西

Git Hook 怎么用

既然 git hook 是调用的脚本，当然我们就要写脚本啦（不用怕，不是真的写复杂的脚本）

来跟着一步步使用

1、新建一个项目，并且 git init

2、进入项目的文件夹 .git/hooks/

3、我们来测试调用一下 commit 时的脚本，所以我们找到 pre-commit.sample 这个文件，并且把 .sample 去掉（前面已经说过了，如果不去掉，这个脚本是不会被触发的）

4、然后写个简单脚本，如下

#!/bin/shecho "commit 脚本被执行"

我们并没有写什么复杂的脚本，就是简单打印一下信息，表示这个脚本被执行了，让我们清楚一下整个调用的流程

然后保存~~~

5、新增一个文件 a.js，然后执行下面的命令

git add .git commit -m "test"

然后发生钩子被成功调用了，因为我们在脚本中的内容被打印出来了

现在你知道 git 是怎么调用 hook 的了吧，就是执行里面的脚本

当然如果我们用在项目中，肯定是比这更加复杂的脚本啦

怎么配置项目使用

当然了，我们在项目中是不可能自己写一个脚本去检查我们的代码的（咦，造轮子）

已经有现成的轮子帮我们做好了这个事情

不过，如果你想自己写个轮子去试验一下也是不错的呢

好的，这个包就是 husky，现在我们就来尝试一下使用这个包，并配合 eslint 去检查我们的项目

1、新建一个项目如下，结构如下

src 就是我们的开发目录，我们以后就是提交里面的 index.js 文件

确保这个项目已经 git init 过，有本次仓库哦

2、现在来安装依赖

npm i husky eslint -D

然后初始化 eslint，这个不是今天的重点

npx eslint --init

npx 作用是，调用项目内部安装的模块，因为以前如果某些模块没有全局安装的话，要在命令行调用，只能通过 npm 的 script 去间接调用

现在可以通过 npx 去调用项目中的模块啦

初始化之后就会给我们添加了一个 eslint 的配置文件

3、添加脚本命令

进入 package.json

{        "scripts": {        、        "precommit":"eslint ./src/*.js"    },
}

上面添加的 precommit 就是 git 的 钩子

前面我们提到过的 git 的脚本，husky 已经在 .git/hooks 下重新添加了自己写的脚本

有 .sample 结尾的就是 原生的 git hook 脚本，没有结尾的，就是安装 husky 之后添加上的

你可以看到了，precommit 添加的命令，后面就是你要执行的动作，比如你要 eslint 检查代码规范，或者 跑测试，都可以

4、现在我们就来尝试一下提交

我们修改 ./src/index.js 文件，随便添加点内容

var a = 111111

然后执行命令

git add .  git commit -m "first commit"

发现 precommi 钩子被调用啦，并且执行了 eslint 检查我们的项目

然后因为本次eslint 检查不通过，所以提交是失败的

如果我们安装提示修正错误之后，再提交，就提交成功了

5、总结

所以我们只需要安装，然后再package.json 的 scripts 中添加命令

你要执行什么钩子，就在 scripts 中添加什么钩子

你要钩子调用时执行什么内容，你就配置相应的钩子的值，是 eslint 还是 测试什么的

怎么使用更加方便

其实我也知道 eslint 好，毕竟可以让项目更加规范些，自己开发项目也更加正规一些

但是奈何啊，每次检查都能爆出几百上千个错误，任谁都顶不住啊

是真的烦啊，特别如果你是项目中期引入的话，那你就等着被审判吧

所以现在有了一个包帮我们减少这方面的恐惧，每次检查的时候，只会检查本次的提交，不会把整个项目都抡一遍

这样相应的，错误就更少一些了，然后这样好处就是，谁的错误谁来抗哈哈哈

这个包的名字就是 lint-staged

1、先来安装

npm i lint-staged -D

2、修改 package.json

{        "scripts": {                "precommit": "lint-staged"    },        "lint-staged":{                "./src/*.js":[                        "eslint"        ]
    },
}

第一，把 scripts 中的 precommit 改成 lint-staged

第二，添加 lint-staged 字段

在这个字段中

属性名表示匹配哪些文件

属性值表示 这些文件要执行哪些命令（可以是字符串，可以是数组，如果是多个命令，就放一个数组里面）

在上面修改的内容中，我们可以看到，是 使用 eslint 检查 ./src/ 下所有的 js

然后当我们提交修改的时候，precommit 钩子就执行 lint-staged 命令，lint-staged 再执行他下面配置给哪些文件的命令

3、我们来试下水，看看是不是只会检测本次提交

既然要试水，我们肯定需要事先添加一个错误的文件，但是现在我们已经使用了 husky，该如何添加上这个错误文件呢？

我们上面已经讲过啦，那现在来玩玩

3.1、在 src 下添加一个含有错误的文件 err.js，内容随便，有错就行

var b= 5555

3.2、提交这个文件 并跳过检测！

git add err.jsgit commit -m "添加错误文件" --no-verify

3.3、好的这样，错误文件就已经被我们提交 了，现在我们需要再去提交一下我们的 index.js （随便修改点内容，但是不要有错误），我修改如下

var a = 111111console.log(a)

3.4、然后提交这个文件

git add ./src/index.jsgit commit -m "检测"

发现提交成功了，并且他没有去检测本次提交外的 err.js 文件，所以这次实验是成功的！

总结

好的，现在我们已经学会 使用 husky 和 lint-stated 来让我们的项目 自动化了

但是然而这也只是基础，主要是记录下如何使用不过我们已经可以初步在项目中使用它啦

后面的话，我们还会记录更加复杂一些的用法！

大公司的每个项目都是必须使用这个提交检测的，所以我们是必须要学会的