我昨天做了一些提交，但没有推动它们。今天我醒来我试图推动它，我有
错误：错误的索引文件 sha1 签名致命：索引文件已损坏
我试过了：
$ del .git\index
$ git reset
然后尝试再次推送我的提交，但它失败了，现在我有了
致命：无法锁定参考“HEAD”：无法解析参考“参考/头/灯模式”：参考损坏
这是怎么回事？我不想丢失我的提交，但更重要的是我不想丢失我对项目的本地更改。
您的 Git 存储库已损坏。目前还不能说是由什么或由谁来完成的。一个常见的罪魁祸首是使用 Dropbox 或类似的工具来存储.git目录。1 一个不太常见的罪魁祸首是实际的硬件故障，例如，旋转生锈的磁盘或 SSD 出现故障。
这条信息：
\n\n\n\n\nRun Code Online (Sandbox Code Playgroud)\nfatal: cannot lock ref 'HEAD': unable to resolve reference\n'refs/heads/light-mode': reference broken\n
发生的原因是您当前的分支 ，light-mode其哈希 ID 存储在 或.git/packed-refs中.git/refs/heads/light-mode。这些文件之一或两个包含垃圾，或者不再包含有效提交的哈希 ID。同样，实际上不可能猜测哪些文件存在哪些特定问题，也不可能猜测哪些程序或硬件故障导致了这些问题。您所做的工作可能已受到不可挽回的损坏或毁坏。
如果您知道昨天提交的正确哈希 ID，您可以尝试使用例如 恢复该哈希 ID 。如果所有其他方法都失败，您可以运行：对于 Git 打印悬空提交或悬空 blob的每个哈希 ID ，Git 还将该提交或文件的内容保存到：查看和文件夹。该文件夹将包含找到的文件的数据。这些文件的名称不再可用，但您可能会认出一些重要内容，因此能够说：啊哈，这就是我想要找回的重要文件，并以这种方式取回它。git checkout hashgit fsck --lost-found.git/fsck/lost-foundcommitsotherother
1一般来说，这是一个非常糟糕的主意，因为 Dropbox 和 Git 会争夺谁将控制特定文件的特定内容。它可能会起作用一段时间，导致一种错误的安全感。然后\xe2\x80\x94通常在重要的演示或课程截止日期或其他\xe2\x80\x94繁荣之前之前，Dropbox决定应该将六个关键的Git文件回滚到某个以前的版本，然后你的工作就消失了。
\n