我知道这是一条古老的线索。。。但随着许多人在寻找如何在Git中撤销这些东西，我仍然认为在这里继续提供提示可能是一个好主意。

当您在gitgui中执行“gitadd”或将任何内容从左上角移动到左下角时，文件的内容存储在一个blob中，文件内容可以从该blob中恢复。

因此，即使文件未提交但必须已添加，也可以恢复该文件。

git init  
echo hello >> test.txt  
git add test.txt  

现在创建了blob，但它被索引引用，因此在重置之前，它不会与git fsck一起列出。所以我们重置。。。

git reset --hard  
git fsck  

您将得到一个悬空blob ce013625030ba8dba906f756967f9e9ca394464a

git show ce01362  

将向您返回文件内容“hello”

为了查找未引用的提交，我在某处找到了一个提示。

gitk --all $(git log -g --pretty=format:%h)  

我把它作为gitgui中的工具，它非常方便。

这救了我的命：https://medium.com/@CarrieGuss/如何从数字-数字-设置-b830b5e3f60c中恢复

基本上，您需要运行：

for blob in $(git fsck --lost-found | awk ‘$2 == “blob” { print $3 }’); do git cat-file -p $blob > $blob.txt; done

然后手动完成痛苦，将文件重新组织到正确的结构。

注意：千万不要使用git重置，如果你不能100%理解它的工作原理，最好不要使用它。

IRL案例示例：

$git fsck--找到丢失

Checking object directories: 100% (256/256), done.
Checking objects: 100% (3/3), done.
dangling blob 025cab9725ccc00fbd7202da543f556c146cb119
dangling blob 84e9af799c2f5f08fb50874e5be7fb5cb7aa7c1b
dangling blob 85f4d1a289e094012819d9732f017c7805ee85b4
dangling blob 8f654d1cd425da7389d12c17dd2d88d318496d98
dangling blob 9183b84bbd292dcc238ca546dab896e073432933
dangling blob 1448ee51d0ea16f259371b32a557b60f908d15ee
dangling blob 95372cef6148d980ab1d7539ee6fbb44f5e87e22
dangling blob 9b3bf9fb1ee82c6d6d5ec9149e38fe53d4151fbd
dangling blob 2b21002ca449a9e30dbb87e535fbd4e65bac18f7
dangling blob 2fff2f8e4ea6408ac84a8560477aa00583002e66
dangling blob 333e76340b59a944456b4befd0e007c2e23ab37b
dangling blob b87163c8def315d40721e592f15c2192a33816bb
dangling blob c22aafb90358f6bf22577d1ae077ad89d9eea0a7
dangling blob c6ef78dd64c886e9c9895e2fc4556e69e4fbb133
dangling blob 4a71f9ff8262701171d42559a283c751fea6a201
dangling blob 6b762d368f44ddd441e5b8eae6a7b611335b49a2
dangling blob 724d23914b48443b19eada79c3eb1813c3c67fed
dangling blob 749ffc9a412e7584245af5106e78167b9480a27b
dangling commit f6ce1a403399772d4146d306d5763f3f5715cb5a    <- it's this one

$git显示f6ce1a40399772d4146d306d5763f3f5715cb5a

commit f6ce1a403399772d4146d306d5763f3f5715cb5a
Author: Stian Gudmundsen Høiland <stian@Stians-Mac-mini.local>
Date:   Wed Aug 15 08:41:30 2012 +0200

    *MY COMMIT MESSAGE IS DISPLAYED HERE*

diff --git a/Some.file b/Some.file
new file mode 100644
index 0000000..15baeba
--- /dev/null
+++ b/Some.file
*THE WHOLE COMMIT IS DISPLAYED HERE*

$git rebase f6ce1a403399772d4146d306d5763f3f5715cb5a

First, rewinding head to replay your work on top of it...
Fast-forwarded master to f6ce1a403399772d4146d306d5763f3f5715cb5a.

制作了一个很小的脚本，以便稍微容易地找到要查找的提交：

git fsck--lost found | grep commit | cut-d“”-f 3 | xargs-i git show \｛\｝| egrp“^commit |日期：”

是的，它可以用锥子或类似的东西做得更漂亮，但它很简单，我只是需要它。可能会为其他人节省30秒。

如果Git尚未垃圾收集，则可以恢复它。

使用fsck获取悬空提交的概述：

$ git fsck --lost-found
dangling commit b72e67a9bb3f1fc1b64528bcce031af4f0d6fcbf

使用rebase恢复悬空提交：

$ git rebase b72e67a9bb3f1fc1b64528bcce031af4f0d6fcbf

如果您还没有对存储库进行垃圾收集（例如，使用git重新打包-d或git gc，但请注意垃圾收集也可以自动进行），那么您的提交仍然存在，只是无法通过HEAD访问。

您可以尝试通过查看git fsck的输出来查找提交。

较新版本的Git有一种叫做“reflog”的东西，它是对ref所做的所有更改的日志（与对存储库内容所做的更改相反）。因此，例如，每次您切换HEAD时（即每次执行git签出以切换分支时），都会被记录。当然，你的git重置也操纵了HEAD，所以它也被记录了下来。您可以以类似于访问存储库的旧状态的方式访问ref的旧状态，方法是使用@符号而不是~，如git-resetHEAD@{1}。

我花了一段时间才明白HEAD@{1}和HEAD~1之间的区别，所以这里有一个小解释：

git init
git commit --allow-empty -mOne
git commit --allow-empty -mTwo
git checkout -b anotherbranch
git commit --allow-empty -mThree
git checkout master # This changes the HEAD, but not the repository contents
git show HEAD~1 # => One
git show HEAD@{1} # => Three
git reflog

因此，HEAD~1表示“在HEAD当前指向的提交之前进行提交”，而HEAD@{1}表示“在其当前指向的位置之前进行HEAD指向的提交”。

这将很容易让您找到丢失的提交并恢复它。