Question

我将代码更改添加到 repo，我可以通过 git log -n1 看到提交 ID。
然后，我使用 git add -u; git commit --amend; git push -f 将新更改组合到预提交 ID。
然后我突然忘记了第二次更改的差异是什么。但是预提交 ID 在 git log 历史记录中消失了。
如何找到丢失的提交？

Answer 1

TL;DR：使用引用日志。

长

git commit --amend 操作具有“将旧提交推到一边”的效果。如果我们绘制提交，根据分支名称找到，我们会得到这样的图片：

... <-F <-G <-H   <--branch

这里的每个大写字母代表一个 Git 提交哈希 ID。 分支名称，在本例中为 branch，包含最新提交 H 的哈希 ID，因此：

git rev-parse branch

打印出这个哈希 ID。 Git 能够使用这个存储的哈希 ID 从提交数据库中读取提交 H。

提交 H 本身在其元数据中存储较早提交 G 的原始哈希 ID。因此，从数据库中读取 H 后，Git 可以找出这个哈希 ID，并使用它从数据库中检索提交 G。

检索到 G 后，Git 拥有来自 G 的元数据，它给出了较早提交 F 的哈希 ID，因此 Git 可以从数据库中检索提交 F。这当然有元数据，包括另一个更早提交的哈希 ID，等等。

当我们以正常方式添加一个 new 提交时，Git 所做的是：

为新提交写出一个新快照（我们将这个新提交称为 I，使用字母表的下一个字母）。
写出提交 I 的元数据：我们的姓名、我们的电子邮件地址、当前日期和时间等。在此元数据中，Git 包含当前提交 H 的哈希 ID，作为提交 I 的父项。
使用 git commit-tree 的内部版本将所有这些作为新提交写入对象数据库。写入提交的行为会产生新的哈希 ID：我们将称之为 I。
将提交 I 的哈希 ID 存储在当前分支名称中。

第 4 步使 branch 指向新提交 I，而不是现有提交 H。当我们绘制结果时，我们有：

... <-F <-G <-H <-I   <--branch

正如您所看到的，从最后开始向后工作的过程现在将找到提交 I，然后提交 H，然后提交 G，依此类推。< /p>

git commit --amend 的作用是绕过当前提交，让新提交 I 直接指向 parent(s ) 当前提交。在这种情况下，由于 H 指向 G，Git 会使新提交 I 直接指向 G：

            H
           /
... <-F <-G <-I   <--branch

Commit H 确实仍然存在，反正有一段时间了。但是无处可找到它的哈希 ID。如果它仍然在你的屏幕上，或者在一个窗口的回滚中，你可以这样抓取它：Git 需要哈希 ID；分支名称只是提供哈希 ID 的一种方式。如果您可以剪切并粘贴哈希 ID，那就没问题了。

但这就是上面reflog这个词的含义。每当 Git 替换存储在分支名称或特殊名称 HEAD 中的值时，Git 将之前的值保存在日志中。 此日志是可选的，但对于您的存储库，它默认为“开启”（至少如果您使用传统的 Git；如果您使用的是 Eclipse 或 JGit 或其他一些仅使用相同的数据库格式）。因此，当 git commit 和 git commit --amend 覆盖存储在分支名称中的哈希 ID 时，它们会在日志中保存上一个哈希 ID。

不带参数运行 git reflog 将转储 HEAD 的引用日志。这是最活跃的 reflog，里面有最多的“东西”，所以它有更多的信息需要筛选。

运行 git reflog branch，如果您在名为 branch 的分支上，会转储 branch 的引用日志。（如果您使用的是 main 或 master，请使用 git reflog main 或 git reflog master。）这将显示该分支名称的更新。

在这两种情况下，您都可以在 git commit --amend 之前找到提交的哈希 ID。这将是被推开的提交的哈希 ID。所以你现在可以运行：

git diff <hash> HEAD

例如比较两次提交。

还有其他使用引用日志的方法。请参阅 documentation for git reflog 和 the documentation for writing revision ID expressions。

如何找到新的强制推送提交 ID 覆盖的预提交 ID？

1 个答案:

长