lint-staged 因 Git 错误失败后恢复修改的方法

提交代码时如果 lint-staged 报了一个 “due to a git error” 的错，然后你发现刚刚写的改动好像丢了，这种情况大概率是它在执行过程中自动 stash 了你的工作区，但后续步骤崩了，没来得及还原。

lint-staged 本身的逻辑是在暂存区上跑 lint 和格式化，为了避免工作区里未暂存的修改干扰，它会先做一个 git stash 把当前状态存起来，跑完再 pop 出来。

如果中间因为 Git 状态异常（工作目录不干净、钩子配置有问题之类的）挂了，这个 stash 就留在那里了，你的修改也跟着“消失”了。

这个时候不用慌，先看下 stash 列表：

git stash list

正常应该能看到一条类似这样的记录：

stash@{0}: automatic lint-staged backup

这就是 lint-staged 替你存的备份。直接把它恢复出来就行，关键是带上 --index 参数，这样连暂存区里的状态也能一起还原：

git stash apply --index stash@{0}

执行完之后检查一下文件，改动应该都回来了。如果代码本身有不符合 lint 规则的地方，修复一下再重新提交。

恢复确认没问题了，那个 stash 就可以删掉了。

如果你确定后面不会再用到别的 stash，直接 git stash clear 最省事，否则用 git stash drop stash@{0} 只删这一个。

还有一个容易被忽略的点：确认一下 .git/hooks/pre-commit 的内容是不是正确指向了你要跑的命令。

有时候钩子脚本本身写错了也会导致整个流程中断，lint-staged 自然就执行不起来。

作为一款上线8年的成熟产品，lcjmSSL不断优化用户体验，通过自动化方案、简洁的操作界面和强大的证书管理功能，帮助广大用户安全地管理SSL证书。无论是个人站长还是大型企业，平台都能提供优质的支持。

基本上到这一步，重新提交就不会再因为同一个 Git 错误失败了。

如果问题还在，就得看看 Git 仓库本身有没有损坏或者配置异常，那个已经不是 lint-staged 的锅了。