git在重置丢失更改后重新设置blob的基础

我使用GitHub for Windows创建了一个Git存储库，并在提交文件之前进行了重置，现在我丢失了所有项目/文件

我发现这些文件有

$ git fsck --lost-found

我的文件位于

.git\lost-found\other

中，我可以使用

$git show SHA

查看它们，但当我执行

$git rebase SHA

时，我得到以下信息：

错误：对象SHA是blob，而不是commit
致命：需要一次修订
无效上游SHA

如何恢复我的文件

---

或者，您可以使用其他程序或语言读取文件吗？

一般来说，我对git recovery不太熟悉，但您可能想看看这个问题：

假设您没有

git添加

，

git隐藏

和

git提交

您的更改。因此，我认为上述问题的公认答案中概述的任何方法都不会奏效

根据您所说的，在执行

git fsck--lost-found

之后，您的文件现在位于

.git\lost-found\other

文件夹中，您可以使用

git show

查看blob

git-rebase

仅适用于提交，而不适用于blob，这就是它不起作用的原因

我认为最安全的方法是为每个blob编写一个脚本或手动执行

git show

，并将输出传输到一个文件。假设有一个名为

4156fb7a

的blob，它最初是存储库中的

README.txt

文件。你会做：

git show 4156fb7a > README.txt

因此，该blob的内容现在可以输出到

README.txt

。如果您手动执行此操作，此过程将非常乏味，但这可能是一种安全的方法

我认为

.git\lost-found\other

文件夹中不存在的任何内容都可以假定为永久丢失。记住要尽早和经常做出承诺。希望有帮助

编辑以更新答案：

@马拉卡，如果没有很多斑点，你可以自己检查。否则，这只是一个猜测，但我猜您可能没有修改所有900个文件。如果你记得你修改了什么，那么恢复工作就容易多了。否则，你可能想看看我下面的建议

我要建议的是一些可能行得通，也可能行不通的事情。并且它假定存在原始文件的另一个文件夹，不管该文件夹是git repo还是其他文件夹。如果您没有其他原始文件夹/回购，那么我下面的想法是无用的

第1步：

编写一个计算机程序，对原始文件夹中的每个文件应用一些校验和，比如SHA1（使用

sha1sum

实用程序；如果没有，则使用

md5sum

）。该计算机程序最终将生成具有以下格式的文本文件：

fullFileName<SP>SHA1 checksum

然后，您的程序将生成一个如下所示的文件。当然，校验和都由以下部分组成：

app/controllers/ApplicationController.rb 01dfea13
assets/utilities.js 55a31aae
README.markdown 9671c6a0

从现在起，我们将上述文件称为

checksumfile

我希望您的原始文件不使用空格。如果有，只需使用其他分隔符来分隔文件名及其校验和

第二步：

现在，编写另一个计算机程序（我们称之为

blobCat

），将

git show

应用于

.git\lost-found\other

文件夹中的每个blob，并将它们输出到另一个文件夹中的任意命名文件中。我们将用

未知lobs

来表示该文件夹。为简单起见，您可以将它们输出为

0.txt

，

1.txt

，

2.txt

，等等，换句话说，只需使用一些整数计数器来命名它们

完成后，编写另一个程序读入

checksumfile

，并使用字典将校验和索引到原始文件名。换句话说，给定上面的

checksumfile

，我们将生成以下字典/哈希：

"01dfea13" => "app/controllers/ApplicationController.rb" 01dfea13
"55a31aae" => "assets/utilities.js" 
"9671c6a0" => "README.markdown" 

现在，遍历由

blobCat

程序生成的

unknownBlobs

文件夹（包含所有

0.txt

、

1.txt

、

2.txt

文件的文件夹），并应用与生成

checksumfile

第一步相同的校验和实用程序。如果您在字典中找到校验和，这意味着blob很可能是该文件的原始版本，您可以安全地将其恢复到另一个文件夹中的层次结构。如果存在校验和冲突，您可能需要检查是否存在另一个具有相同校验和的blob，尽管这种情况不太可能发生

对于

unknownBlobs

文件夹中的任何blob，如果在字典中找不到校验和，则这可能意味着以下任一情况：

它是从原始存储库中的某个文件中修改的

它不是存储库的一部分

这是一个新创建的文件，从未被跟踪

在任何情况下，只要跟踪那些在字典中找不到的blob，并在一切结束时输出它们的名称。这应该是一组相当小的blob，因此您可以手动检查它们并确定它们是否是原始存储库的一部分，然后将它们复制到目标位置（如果是）

---

上面的内容听起来很乏味，但我认为这比自己检查所有blob要快得多，假设有很多blob。

可能是重复的否，我的文件没有提交，所以我（认为）HEAD中没有任何内容，$git reflog只返回我做的第一次提交。啊，然后可能会检查这个答案-唯一的问题是恢复文件的名称（和路径），我有900多个文件：s@Malaka我将根据您的情况更新我的答案不幸的是，我没有一个包含所有数据的远程存储库，我只有其他文件夹上的一些版本。但是早上我用usb钥匙复制了这个文件夹的一部分，我会尝试重新复制

"01dfea13" => "app/controllers/ApplicationController.rb" 01dfea13
"55a31aae" => "assets/utilities.js" 
"9671c6a0" => "README.markdown"