Git add + Git reset hard删除工作副本文件 - 撤消？

Question

我使用git add添加了一个目录，但后来发现里面有错误的文件，于是我使用git reset --hard回到最新提交的版本，但我不知道git也会删除工作副本中添加的文件。

请问有什么方法可以撤销这个操作吗？

- user1354743

---

可能是撤销 git reset --hard 的重复问题。 - Wayne Conrad

Answer 1

当你使用git add命令添加一个文件时，它会被添加到对象数据库和索引中。运行git reset会更新索引和工作目录，但不会从对象数据库中删除这些文件。它们仍然存在于未根据 ("悬挂") 对象中。你可以运行git文件系统检查器git fsck来查看哪些项目是 "悬挂" 的。你应该会看到以下报告：

% git fsck
dangling blob 1ff0c423042b46cb1d617b81efb715defbe8054d
dangling blob 1bc915c5cb7185a9438de28a7b1a7dfe8c01ee7f
dangling blob a8c86221b400b836010567cc3593db6e96c1a83a
dangling blob 46ff0854663aeb2182b9838c8da68e33ac23bc1e
dangling blob 21a96a98ed84d45866e1de6e266fd3a61a4ae9dc
... etc ...

如果您也遇到了悬挂树（dangling tree），您可能可以恢复文件名与blob ID的映射关系。如果您有一些悬挂树：

dangling tree 57623d711c18d819831f24a9456f0660e9dbe596

然后您可以通过运行git ls-tree命令来显示树的内容：

% git ls-tree 57623d711c18d819831f24a9456f0660e9dbe596
100644 blob 21a96a98ed84d45866e1de6e266fd3a61a4ae9dc file1.txt
100644 blob 46ff0854663aeb2182b9838c8da68e33ac23bc1e file2.txt

这意味着blob 46ff0854663aeb2182b9838c8da68e33ac23bc1e 最初是作为file1.txt添加的。 但是很可能您没有将树添加到对象数据库中，您需要检查每个文件以确定您想要保存它的位置。 您可以使用git cat-file命令获取blob的内容。例如，将其保存到recovered.bak:

% git cat-file blob 46ff0854663aeb2182b9838c8da68e33ac23bc1e  > recovered.bak

- Edward Thomson

---

我曾认为 git add 只是将文件添加到索引中，而需要 git commit 才能将索引中的文件添加到对象数据库。 - Wayne Conrad

@WayneConrad 将 blob 添加到索引中将把它放入对象数据库以及索引中。这对于这些类型的情况非常方便，这样您就可以在修改工作目录后检出索引。 - Edward Thomson

另外，由于您必须对其进行哈希以计算要放入索引中的对象ID，因此最好将其放入对象数据库中，这样在提交时就不必再次哈希文件。 - Edward Thomson

Answer 2

你可以运行 Git 文件系统检查器 git fsck 来查看哪些项目是“悬空”的。

使用最新的 Git 进行操作：索引中的解析撤消信息没有受到GC的保护，这已在 Git 2.38（2022年第三季度）中得到了纠正。

请查看提交 e0ad139（2022年7月11日）和提交 5a5ea14（2022年6月9日），作者为Junio C Hamano（gitster）。
^{（由Junio C Hamano -- gitster --合并于提交 418aef9，2022年7月19日）}

修订：将需要解决撤消的Blob标记为可达

在cfc5789 ("resolve-undo: record resolved conflicts in a new index extension section", 2009-12-25, Git v1.7.0-rc0 -- merge)中，resolve-undo扩展被添加到索引中。
当路径被解决（例如使用“git add”^(man)）时，此扩展记录了冲突路径的blob对象名称及其模式，以允许使用“checkout -m path”撤消解决方案。
在我们拥有索引中的resolve-undo信息时，应该保护这些blob对象不受垃圾回收的影响（否则未解决操作可能会尝试使用已经被修剪掉的blob对象）。

但是从索引中调用的mark_reachable_objects()代码忘记了这样做。
教add_index_objects_to_pending()助手还添加由resolve-undo扩展引用的对象。

还要对“fsck”进行匹配更改，其中的代码与可达性内容非常相似，但所有这些内容都有并行实现，这些内容可能（或可能不会）希望统一。

- VonC