大多数命令：
fatal: your current branch appears to be broken
.git / refs / heads / master：
$ cat .git/refs/heads/master
.git / refs / heads / master的文件内容：
'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
$ git status
new file: ...
new file: ... [for every file in the repository; expected since on a corrupted branch]
我不确定我是否会责怪git --amend，因为它似乎有些良性；也许发生了其他事情。
要解决此问题，就像从.git / logs / refs / heads / master的最新提交中获取哈希并将其手动插入.git / refs / heads / master一样简单？如果可以的话，我该怎么做
如果是这样，我是否应该销毁有问题的提交（这样以后就不会破坏内容了，比如说git-repack之类的东西）？
当我尝试less .git/logs/refs/heads/master并从表格的最后一行中提取[edit：typo] first 哈希时...
...
[hash for HEAD~2] [hash for HEAD~1] [authorname] ...
[hash for HEAD~1] [hash for HEAD] [authorname] ...
^^^^^^^^^^^^^^^^^ (corrupted)
EOF
...然后粘贴到.git / refs / heads / master文件中，我现在坚持使用...
$ git fsck
error: inflate: data stream error (unknown compression method)
error: unable to unpack header of .git/objects/8f/1da374ffac3711f8cdde57379f90cb03bbb9ea
error: 8f1da374ffac3711f8cdde57379f90cb03bbb9ea: object corrupt or missing: .git/objects/8f/1da374ffac3711f8cdde57379f90cb03bbb9ea
error: inflate: data stream error (unknown compression method)
error: unable to unpack header of .git/objects/ac/2fcd052804fb7adac465220da5bcb04d008fc7
error: ac2fcd052804fb7adac465220da5bcb04d008fc7: object corrupt or missing: .git/objects/ac/2fcd052804fb7adac465220da5bcb04d008fc7
Checking object directories: 100% (256/256), done.
Checking objects: 100% (1147/1147), done.
error: inflate: data stream error (unknown compression method)
error: unable to unpack 8f1da374ffac3711f8cdde57379f90cb03bbb9ea header
error: inflate: data stream error (unknown compression method)
error: unable to unpack 8f1da374ffac3711f8cdde57379f90cb03bbb9ea header
fatal: loose object 8f1da374ffac3711f8cdde57379f90cb03bbb9ea (stored in .git/objects/8f/1da374ffac3711f8cdde57379f90cb03bbb9ea) is corrupt
我可以尝试销毁松散的对象，但是我不确定它是否又是指向也必须销毁的更多损坏对象的指针（例如，树）。如果我知道该命令，我当然可以尝试销毁该对象（或者可以尝试rm进行备份）；我应该尝试吗？
此外，我该如何从这个混乱中修复USB密钥和其他存储库？谢谢。
（对新手来说可能有用的参考，不太可能帮助有能力回答以下问题的人：https://aboullaite.me/deep-dive-into-git-git-refs/） （类似问题fatal: your current branch appears to be broken －未指定错误原因；很多情况都可能导致此错误）
编辑：
我为上面列出的每个对象都做了rm .git/objects/...，现在我有了...
$ git fsck
Checking object directories: 100% (256/256), done.
Checking objects: 100% (1147/1147), done.
error: refs/remotes/origin/HEAD: invalid sha1 pointer 0000000000000000000000000000000000000000
error: refs/remotes/origin/master: invalid sha1 pointer 0000000000000000000000000000000000000000
error: HEAD: invalid reflog entry 8f1da374ffac3711f8cdde57379f90cb03bbb9ea
error: refs/heads/master: invalid reflog entry 8f1da374ffac3711f8cdde57379f90cb03bbb9ea
error: bad ref for .git/logs/refs/remotes/origin/HEAD
error: bad ref for .git/logs/refs/remotes/origin/master
error: ac2fcd052804fb7adac465220da5bcb04d008fc7: invalid sha1 pointer in cache-tree
broken link from tree b0d598ef5427d59ed31eb1b315c761fc89af40b7
to tree ac2fcd052804fb7adac465220da5bcb04d008fc7
dangling blob f4e39c36cc8df3f9f324c0ccca4ed6a7a3ffe6ac
dangling tree 068716abcf815b4eaf8f0fe74c3020bf6251bba0
dangling blob fb4cfe7c94e8b4d800fdb4935806577b2b99fd94
dangling blob 35cf2ca2ed03811c14f1598c50daacfab9032b8f
missing tree ac2fcd052804fb7adac465220da5bcb04d008fc7
dangling blob d056e38af637cf0de76dac5689a8c5e735d75793
dangling blob 3b3903cc7b4eb035e9c4508024acc3f81c015741
dangling blob b09c3cc95935a327ecf7fad8374f14c4e320f67e
答案 0 :(得分：2)
问题的根源很可能是您在操作系统将写入 USB密钥之前或期间删除了USB密钥。这留下了许多损坏的文件。
由于任何原因计算机不正确关闭而损坏的文件-拉USB密钥是一种，但操作系统崩溃，电源故障，计算机着火等也是如此-往往会损坏< em>最近写入的文件。刚静静地坐着的文件倾向于保持完整。这里有很多警告，但是这个一般原理在这里适用。
如果更新分支，则包含分支信息的文件可能会损坏。
在这里，损坏的文件包括.git/refs/heads/master。该文件应包含41个字节，其中包括提交的哈希ID的40个字节的文本表示形式，应将其视为分支master的尖端，后跟ASCII换行符。 没有确定的方法猜测哪个提交是正确的提示提交，这就是为什么Git会存储以下问题的答案：“提示提交的哈希ID是多少？ master *在某些文件中。
（在某些情况下，.git/packed-refs中可能有一个有效的答案，但是通常，如果存在.git/refs/heads/master，它应该保留正确的答案。答案随时间的变化，创建新的提交，运行git reset，运行git branch -f等）。
损坏的文件可能包含.git/index，该文件包含Git的 index 或临时区域。这两个术语在Git中具有相同的含义，而对于同一文件，还有第三个现在很少使用的术语 cache 。除非在使用索引进行有冲突的合并时，索引文件中的 in 中的内容大多数都是很容易重新计算的：Git使用它来使事情变得更快，例如，作为缓存，因此是第三个很少使用的术语。
如果（在大多数情况下）高速缓存不包含无法重新计算的内容，则可以简单地删除 .git/index，然后运行git reset对其进行重新计算。那将使所有“新文件...”消息消失，唯一丢失的是您是否已上演某些特定更新。
通常在此处出现 一词是因为索引包含要放入 next 提交中的所有blob对象（“文件”）的哈希ID 。如果您做了一些不寻常的事情，例如创建文件的新的唯一版本并将其放入索引，然后将其从其他任何地方删除，则可能无法在任何地方轻易找到该文件的唯一版本的哈希ID。使用git add -p或git reset -p登台不同于已提交版本和工作树版本的文件的第三个变体时，可以得到此信息。在这种情况下，删除并重新创建索引（使用rm .git/index; git reset）将是重新构建该文件的最简单方法是重新运行git add -p或git reset -p操作。
在您的情况下，索引似乎已被完全删除，导致Git声称每个文件都是新文件。如果运行rm .git/index，则得到的结果与此相同，因此最好运行git reset。但是，由于此消息，肯定还有其他事情在发生：
error: ac2fcd052804fb7adac465220da5bcb04d008fc7: invalid sha1 pointer in cache-tree
此处的cache-tree使用旧名称 cache 来引用索引中的内容。但是，由于这是“缓存”，因此删除并重新创建索引 可能会克服问题，具体取决于其他因素。
损坏的文件可能包含您的某些工作树文件。 Git无法帮助您解决这些问题：管理这些文件的是计算机的其余部分。当您git checkout进行一些现有的提交时，Git将文件的副本写入到您的工作树中，从而使它们处于您可以查看和使用的形式，但是在那之后，这一切您的/您的计算机的管理。
损坏的文件可能包含Git的一些内部对象。就您而言，这显然确实发生了：
error: unable to unpack header of .git/objects/8f/1da374ffac3711f8cdde57379f90cb03bbb9ea
error: 8f1da374ffac3711f8cdde57379f90cb03bbb9ea: object corrupt or missing: .git/objects/8f/1da374ffac3711f8cdde57379f90cb03bbb9ea
这意味着对象8f1da374ffac3711f8cdde57379f90cb03bbb9ea已损坏。没有进一步的信息，就不可能知道该对象的类型是什么，更不用说其中的数据以及它们是否有价值。
损坏的文件可能包括各种刷新日志，存储在.git/logs/中。在这种情况下，您得到了：
invalid reflog entry 8f1da374ffac3711f8cdde57379f90cb03bbb9ea
和：
error: refs/heads/master: invalid reflog entry 8f1da374ffac3711f8cdde57379f90cb03bbb9ea
使用相同的数字。那就是我们刚才看到的损坏的对象哈希ID。由于需要 分支名称来指向 commit 对象，因此我们现在可以猜测8f1da374ffac3711f8cdde57379f90cb03bbb9ea是一个提交对象，它没有被损坏。这可能是最近创建的提交，例如git commit --amend所做的提交。
从所有这一切，我们可以得出结论，但仍然是一个猜测，git commit --amend提交本身已损坏，并且master中损坏的哈希ID应该是文本{{1 }}。索引可能已被损坏或完全删除，但是通常只要删除它并重建其缓存方面就足够安全了，因此您可以再次删除它（如有必要），然后在拥有明智的“当前提交”之后从当前提交中重建它”。您的某些reflog可能已损坏，但是无论如何reflog都是辅助数据：它们中的任何内容对于Git自身的操作都不重要，因此可以将这些损坏的记录截断。最大的问题是损坏的8f1da374ffac3711f8cdde57379f90cb03bbb9ea文件。
如果您愿意丢失该提交，可以 简单地删除损坏的对象并将有效的哈希ID放入.git/objects/中就可以了。当您这样做时，您的fsck仍会抱怨：
.git/refs/heads/master
现在，第一行仍然引用从error: ac2fcd052804fb7adac465220da5bcb04d008fc7: invalid sha1 pointer in cache-tree
broken link from tree b0d598ef5427d59ed31eb1b315c761fc89af40b7
to tree ac2fcd052804fb7adac465220da5bcb04d008fc7
中读取的内容。通过将其哈希ID写入.git/index，删除和重置将根据您选择的提交重建索引/缓存。 如果树对象.git/refs/heads/master未在存储库中的其他任何地方使用，则可能会使您拥有完整的存储库。
如果不是，那么只有两种方法可以使此特定的Git存储库自洽：
删除 all 提交及其直接或间接引用该树对象的所有后代（如果有）。
获取或重建丢失的对象。如果它在其他Git存储库中（此库的某个副本），则这是获取它的简便方法。在具有它的存储库中运行ac2fcd052804fb7adac465220da5bcb04d008fc7。结果是树的文本表示。使用git cat-file -p ac2fcd052804fb7adac465220da5bcb04d008fc7在USB密钥存储库中创建对象，使其现在存在。
请注意，此获取或重建方法适用于任何损坏或丢失的对象：哈希ID在每个克隆中是全局唯一的，因此如果可以 >找到另一个克隆中的对象，您可以从另一个克隆中复制对象。
我如何从这个混乱中修复USB密钥和其他存储库？
最清晰的方法是使用其他一些克隆。查找相同存储库的未损坏克隆。对该克隆进行克隆，以得到新的“已修复克隆”结果。向该新克隆中，从损坏的存储库中添加 new 对象，这些对象本身是未损坏的新标签，树，blob和提交。 （您可以使用git hash-object -t tree -w直接复制它们，也可以使用cp。）这样，您仅从损坏的克隆中读取。
当您击中损坏的物体时，请恢复尽可能多的有用数据，然后继续前进。
结果始终是一个良好且有效的克隆，其中包含尽可能多的已恢复数据。 您将知道确切的恢复内容和丢失的内容。您甚至可以提交一些丢失的文件（因为其内部blob对象被不可恢复地损坏）：您可以将注释保存在某个地方，也许使用git cat-file -p <hash> | git hash-object -t <type> --stdin或只是在纸上，然后再重新构造例如，您以后可以。
此方法往往会很慢且很痛苦。您尝试过的方法-尝试就地修复损坏的克隆-更快，更容易，但可能会给您带来一些隐藏的问题（例如，您不记得的丢失的提交是在之后出现的因损坏而故意破坏的那一类。
答案 1 :(得分：0)
[暂时回答自己的问题，但我想接受一个确实有效的答案]
Private Sub UserForm_MouseMove(ByVal Button As Integer, ByVal Shift As Integer, _
ByVal X As Single, ByVal Y As Single)
If UserForm1.ActiveControl.Name = "List1" Then
UserForm1.TextBox1.SetFocus
End If
End Sub
以使其没有损坏git fsck；不确定如何在裸仓库中运行，所以我将其克隆到临时仓库中...）git fsck恢复存储库这显然是一个无法解决的问题，但暂时可以解决（“足够好”），但是解决此问题的正确方法可能会使社区受益。