lint-staged如何作到只lint staged?

介绍

lint-staged针对暂存的git文件运行linters而且不要让 💩 进入你的代码库！

开始

去年分享过一个主题——规范化工做流之约定式提交，主要内容是提交代码时对暂存区代码格式的校验和提交信息规范校验。当时就接触到了lint-staged，只知道这个工具能针对暂存区的文件处理，并未深刻了解， 那时候就有一些疑问埋在内心，最近得空，特来解疑。

疑问点：

git分为暂存区和工做区，若是一个文件同时存在在两个区（某文件git add后又再次修改，以下图test2.js ），此时本地的文件内容其实是等同未暂存区的，根据介绍lint-staged会lint暂存区的那个版本，那么这是怎么作到的呢？

先猜想：

使用SourceTree提交代码偶尔会比较卡，稍微窥得点儿（未暂存文件消失再重现），所以猜想多是用了什么方法先清除未暂存文件而后再恢复。

猜想归猜想，仍是要验证一下。

结论

通过分析，lint-staged在执行检查前会保存当前文件状态，而后清除掉修改，再执行lint任务，执行完毕再恢复。

重点就是：如何保存？如何恢复？

我总结出lint-staged的流程大体以下

这样就很清晰了，由图可知，上述疑问点为红色流程部分，下面咱们来分析一下流程中的具体实现。

分析

流程大体分为四部分：

• Stashing changes
• Running linters
• Updating stash
• Restoring local changes

咱们来分别看一下每一步作了什么

保留案发现场并清除干扰（Stashing changes...）

git write-tree // 获得 indexTree
git add .
git write-tree // 获得 workingCopyTree
git read-tree $indexTree
git checkout-index -af // 清除文件修改（未暂存的test2.js被清除）

根据以上操做步骤得知，lint-staged经过tree对象来保存暂存区目录和工做区目录，并清除掉工做区修改文件，操做完成后，能够看到，被修改的test2.js已经被清除（以下图）。

执行代码检查任务（Running linters...）

按照配置的命令走，好比配置了 "*.js": "eslint"

eslint test2.js test.js

更新（Updating stash...）

上一步（Running linters）若是有检查到错误，直接跳过走下一步（Restoring local changes）

git write-tree // 获得 formattedIndexTree

这里须要特别声明一下，

若是上一步（Running linters）未检测到错误，那么这里获得的formattedIndexTree 会和第一步的indexTree同样，若是检测到错误并将修复后文件添加到暂存区，如配置命令是eslint --fix , git add的话，那么代码被修复过，formattedIndexTree 与indexTree不一样

恢复案发现场（Restoring local changes...）

git read-tree $workingCopyTree // 首先恢复工做区内容，对应第一步的git add .
git checkout-index -af // 清除工做区修改
git read-tree $formattedIndexTree // 恢复暂存区内容 
git apply $patch // 若是修复了代码，也应用到工做区

总结

归根结底，都是git对象的操做。

• git-read-tree - Reads tree information into the index
• git-write-tree - Create a tree object from the current index
• git-checkout-index - Copy files from the index to the working tree