2

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

我找到了文件

$ git fsck --lost-found

我的文件在里面.git\lost-found\other,我可以查看它们,$ git show SHA但是当我这样做时,$ git rebase SHA我得到了:

错误:对象 SHA 是一个 blob,而不是致命的提交
:需要一个
无效的上游 SHA修订

我可以做些什么来恢复我的文件?

或者,可以用其他程序或语言读取文件吗?

4

1 回答 1

2

我一般不太熟悉 git 恢复,但您可能想看看这个 stackoverflow 问题:

意外恢复为 master,丢失未提交的更改

假设你没有git add,你git stashgit commit变化。所以我认为上述问题的公认答案中概述的方法都不起作用。

根据您所说,执行后git fsck --lost-found,您的文件现在在.git\lost-found\other文件夹中,您可以使用git show <SHA1>. git rebase仅适用于提交而不适用于 blob,这就是它不起作用的原因。

我认为最安全的方法是编写脚本或git show为每个 blob 手动执行并将输出通过管道传输到文件。假设有一个名为 的 blob 4156fb7a,它最初是README.txt存储库中的文件。你会这样做:

git show 4156fb7a > README.txt

这样该 blob 的内容现在将输出到README.txt. 如果您手动执行该过程将是乏味的,但这可能是一种安全的方法。

我认为.git\lost-found\other可以假定文件夹中不存在的任何内容都将永远丢失。记得尽早并经常提交。希望有帮助。

编辑以更新答案:

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

我要建议的是可能会或可能不会成功的东西。它假设存在原始文件的另一个文件夹,无论该文件夹是 git repo 还是其他。如果您没有其他原始文件夹/存储库,那么我在下面的想法是无用的。

步骤1:

编写一个计算机程序,对原始文件夹中的每个文件应用一些校验和,比如 SHA1(使用该sha1sum实用程序;如果不存在,请使用)。md5sum该计算机程序最终将生成具有以下格式的文本文件:

fullFileName<SP>SHA1 checksum

where<SP>代表一个空间。因此,假设我在原始文件夹/存储库中有以下文件:

app/controllers/ApplicationController.rb
assets/utilities.js
README.markdown

然后您的程序将生成一个类似于以下内容的文件。校验和当然都是由以下组成的:

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

从现在开始,我们将参考上述文件checksumfile

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

第2步:

现在,编写另一个适用于文件夹中每个 blob 的计算机程序(我们称之为blobCat),并将它们输出到另一个文件夹中的一些任意命名文件。我们将用 表示该文件夹。为简单起见,您可以将它们输出为、、等,换句话说,只需使用一些整数计数器来命名它们。git show.git\lost-found\otherunknownBlobs0.txt1.txt2.txt

完成后,编写另一个读入 的程序checksumfile,并使用字典将校验和索引到原始文件名。换句话说,鉴于checksumfile上述情况,我们将生成以下字典/哈希:

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

现在,遍历程序unknownBlobs生成blobCat的文件夹(包含所有0.txt, 1.txt,2.txt文件的文件夹),并应用与在第一步中生成checksumfile. 如果您在字典中找到校验和,这意味着该 blob可能最初是该文件,您可以安全地将其还原到另一个文件夹中的层次结构。如果存在校验和冲突,您可能需要检查是否存在具有相同校验和的另一个 blob,尽管这不太可能发生。

unknownBlobs对于在字典中找不到校验和的文件夹中的任何 blob ,这可能意味着以下任何一种:

  1. 它是从原始存储库中存在的某个文件修改的
  2. 它不是存储库的一部分
  3. 这是一个从未被跟踪过的新创建的文件

在任何情况下,只需跟踪那些在字典中找不到的 blob,并在所有内容的末尾输出它们的名称。这应该是一组相当小的 blob,因此您可以手动检查它们并确定它们是否是原始存储库的一部分,然后将它们复制到它们的目标位置。

以上听起来很乏味,但我认为这比尝试自己检查所有斑点要快得多,假设它们有很多。

于 2013-12-17T00:09:07.940 回答