一个项目往往不只一个人开发，多人合作自然需要版本控制来合理管理代码，比如 git、svn 等。个人喜欢 git，以及直男社区 github。git 除了能管理代码版本，还可以在 npm script 里运用，不然我也不会在这啰嗦那么多做铺垫了。git 在 npm script 的运用主要体现在 pre 和 post 的钩子上，也就是大家熟知的 git hooks，能帮助我们在代码提交（commit）和获取时（push）做一些事情。
说说场景
- 本地仓库配置
pre-commit和pre-push，是给要提交的代码做检查； - 远程仓库配置
pre-receive，是给拉取下来的代码做检查，以确保符合本地代码规范，假如没有这步，本地开发者偷懒使用--no-verify（或-n）就可以规避本地代码检查；
注：有些懒可以偷，有些不可以。有些懒，虽一时方便了自己，但长远来看，不仅是坑了自己，更是坑了整个团队。
全面检查
全面检查，就是对匹配文件的全量遍历。
前端社区中 npm script 结合 git-hooks 的方案，个人还是喜欢 husky，就是好用嘛，而且还支持跟多的 git hooks 工具，比如后面要说的 lint-staged。还等什么 =>
安装依赖包
npm install husky -D
// 或
yarn add husky -D
复制代码编写
{
"scripts": {
"lint:js": "# 检查 js \n eslint ./src/**/*.js",
"test": "# 单元测试 \n cross-env NODE_ENV=test mocha tests/"
},
"husky": {
"hooks": {
"pre-commit": "npm run lint:js",
"pre-push": "npm run test"
}
},
}
复制代码剖析
1.安装依赖包 husky 后，可查看 .git/hooks 目录，都是 husky 的钩子
执行
1.代码开发完毕，准备提交到本地仓库
git commit -am "git hooks 的使用"
复制代码此时会调用 pre-commit，发现错误：
2.解决了有错误的 request.js 问题，提交到远程分支上，又发现单元测试环节出现了问题：
3.解决单元测试错误就能提交到远程分支仓库了
搭载 lint-staged 让你飞
以上基本实现我们所需要的，但是...现实的情况是，有些场景我们会接手他人项目，如果按上面步骤走，每次提交代码就会检查所有代码（上面例子只检查 js 的代码）就会发现有 n 个文件有警告或错误（成百上几个），瞬间处于崩溃边缘，想重构或跑路节奏。
lint-staged 当然就是帮助我们解决这类场景问题的，加上 prettier 如虎添翼。
安装依赖包
npm install lint-staged prettier -D
// 或
yarn add lint-staged prettier -D
复制代码编写
{
"scripts": {
"lint:js": "# 检查 js \n eslint ./src/**/*.js",
"test": "# 单元测试 \n cross-env NODE_ENV=test mocha tests/"
},
"husky": {
"hooks": {
"pre-commit": "lint-staged",
"pre-push": "npm run test"
}
},
"linters": {
"src/**/*.js": [
"prettier --tab-width 4 --write",
"eslint --fix",
"git add"
],
"src/**/*.{css, less}": [
"prettier --tab-width 4 --write",
"stylelint --fix",
"git add"
]
},
"ignore": [
"**/dist/*.min.js"
]
}
复制代码剖析
lint-staged是一个前端文件过滤工具，不会格式化任何东西，没有代码规则配置文件，需要自己配置；lint-staged它的作用是指检查当前改动的文件（或者说当次要提交到本地仓库的文件）;pre-commit钩子启动会执行lint-staged命令，然后对本次 commited 中的所有.js和.{less, css}文件执行exlint --fix、stylelint --fix和git add;prettier代码格式优化，它能优化js, jsx, ts, css, less, scss, json, md, ...，保证团队代码风格是相当有用的。
如果，你嫌lint-staged 写在 package.json 臃肿，可以抽取出来放到 .lintstagedrc 中：
{
"linters": {
"src/**/*.js": [
"prettier --tab-width 4 --write",
"eslint --fix",
"git add"
],
"src/**/*.{css, less}": [
"prettier --tab-width 4 --write",
"stylelint --fix",
"git add"
]
},
"ignore": [
"**/dist/*.min.js"
]
}
复制代码执行
git commit -am "本次提交解释说明"
复制代码假如 src/utils 目录下有 request.js 和 index.js 两个文件，其中两个文件代码都有错误，但是 index.js 是别人写的，属于历史版本（之前怎么提交到仓库或许是因为没做检查或者跳过检查了吧）。本次其实只改动了 request.js 文件，如果按照前面步骤，就会检查出两个文件都有问题，而这又不是我们想要的，因为 index.js 文件不是我写的，里面的代码不好改动（业务逻辑和功能逻辑不明白），这个时候，lint-staged 的价值就提现出来了，只报出 request.js 文件的错误（知我者）：
多几句嘴
现在可以在你的项目中应用起来了，还等什么！！！
You can
上一章：npm script 复杂场景的应用