介绍

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