如何检查 Git 提交是否存在于引用日志中

简介

在本次实验中，你将学习如何使用强大的 git reflog 命令来跟踪 Git 仓库中 HEAD 的历史记录。你将了解到引用日志（reflog）如何充当你操作的个人日记，记录提交、合并、变基等操作，即使是那些不再能被任何分支访问到的提交也会被记录。

通过实际操作步骤，你将学会列出引用日志条目、在引用日志中搜索特定的提交哈希，并了解引用日志条目如何过期。本次实验将让你掌握如何将引用日志作为恢复丢失工作和了解仓库历史的重要工具。

Skills Graph

运行 git reflog 列出条目

在这一步，我们将探索一个强大的 Git 命令 git reflog。你可以把引用日志（reflog）想象成你在 Git 仓库中所做的每一个操作的个人日记。它会记录你何时进行了提交、修改了提交、合并了分支、进行了变基，甚至是你意外重置了仓库的情况。

git reflog 命令在恢复丢失的提交或了解仓库历史方面非常有用，即使这些提交不再能被任何分支访问到。

让我们查看 my-time-machine 仓库的引用日志。首先，确保你处于正确的目录中：

cd ~/project/my-time-machine

现在，运行 git reflog 命令：

git reflog

你应该会看到类似如下的输出：

a1b2c3d (HEAD -> master) HEAD@{0}: commit: Send a message to the future
a1b2c3d (HEAD -> master) HEAD@{1}: initial commit (master)

让我们来分析一下这个输出：

• a1b2c3d：这是简短的提交哈希，是每个提交的唯一标识符。
• (HEAD -> master)：这表明 HEAD（你当前的位置）和 master 分支都指向这个提交。
• HEAD@{0}：这是 HEAD 当前状态的引用日志条目。花括号 {} 中的数字表示这个条目是多少步之前创建的。{0} 是最近的条目。
• HEAD@{1}：这是上一个引用日志条目。
• commit: Send a message to the future：这是所执行的操作（提交）以及提交信息。
• initial commit (master)：这表示仓库创建时的初始提交。

引用日志按时间顺序显示了你的 HEAD 所到过的位置。这与 git log 不同，git log 显示的是从当前分支可访问的提交历史。引用日志跟踪的是 你 的操作，这使其成为恢复丢失工作的安全保障。

理解引用日志就像是拥有一张你时间旅行冒险的详细地图。它会显示你去过的每一个地方，即使你后来已经转移到了不同的时间线（分支）。

在引用日志中搜索提交哈希

在上一步中，我们看到了 git reflog 的输出。引用日志中的每个条目都对应着你仓库中 HEAD 的一个特定状态。这些状态由提交哈希来标识。

有时候，你可能需要在引用日志历史中找到一个特定的时间点，也许是为了恢复丢失的提交，或者是想看看仓库在某个特定时间的状态。你可以使用 git reflog 输出中的提交哈希来引用这些特定的时间点。

让我们尝试查看仓库在初始提交时的状态。从上一步的 git reflog 输出中，初始提交条目大致如下：

a1b2c3d (HEAD -> master) HEAD@{1}: initial commit (master)

初始提交的提交哈希是 a1b2c3d（你的哈希值会不同）。我们可以在 Git 命令中使用这个哈希来引用那个特定的状态。

例如，要使用初始提交的哈希查看其提交详情，你可以使用 git show 命令，后面跟上哈希值。请将 a1b2c3d 替换为你 git reflog 输出中初始提交的实际哈希值。

git show a1b2c3d

你应该会看到类似如下的输出，显示初始提交的详细信息：

commit a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9
Author: Jane Doe <[email protected]>
Date:   Mon Aug 7 10:00:00 2023 +0000

    Send a message to the future

diff --git a/message.txt b/message.txt
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/message.txt
@@ -0,0 +1 @@
+Hello, Future Me

这展示了你如何使用引用日志中的提交哈希来精确确定仓库历史中的特定时刻。这是在 Git 中导航和从错误中恢复的一项关键技能。

请记住，引用日志是你的安全保障。即使某个提交不再是分支历史的一部分，只要它还在引用日志中，你通常就可以使用其哈希找到并恢复它。

测试过期的引用日志条目

在这一步，我们将了解 Git 如何管理引用日志，以及条目最终是如何过期的。默认情况下，Git 会在一定时间内保留引用日志条目。可访问的条目（即被分支或标签指向的条目）会保留 90 天，而不可访问的条目（即没有被任何对象指向的条目）会保留 30 天。在这些期限过后，Git 的垃圾回收机制可能会将它们移除。

在这个实验中，我们无法模拟时间的流逝来观察条目自然过期的情况，但我们可以使用特定选项手动触发 Git 的垃圾回收机制，以清理（移除）旧的引用日志条目。

重要提示： 运行此命令会根据配置的过期时间移除较旧的引用日志条目。在实际场景中，除非你有特定的理由要清理旧的引用日志条目，否则通常不需要手动运行此命令。

首先，确保你位于 my-time-machine 目录中：

cd ~/project/my-time-machine

现在，让我们运行带有清理引用日志条目选项的垃圾回收命令。我们将为不可访问的条目设置一个非常短的过期时间，以演示其效果。

git gc --prune=now --aggressive

此命令告诉 Git 立即运行垃圾回收（--prune=now），并积极地（--aggressive）清理松散对象并移除不可访问的引用日志条目。

运行该命令后，让我们再次检查引用日志：

git reflog

你可能会发现一些较旧的条目不见了，特别是如果你在本次实验之前进行了更多操作的话。在我们这个只有两条引用日志条目的简单仓库中，这两条条目可能仍然存在，因为它们相对较新，而且其中一条仍然可以通过 HEAD 和 master 访问。但是，如果你有更复杂的历史记录，包含不可访问的提交，此命令将根据过期设置清理它们。

这里的关键要点是，引用日志并非永久保留。Git 会清理旧条目以节省空间。不过，对于典型的开发工作流程，默认的过期时间通常足以让你从大多数错误中恢复。

了解引用日志条目有过期时间，有助于你认识到创建有意义的提交和分支以保存项目历史中重要节点的重要性。

总结

在本次实验中，我们学习了如何使用 git reflog 命令查看 Git 仓库中 HEAD 指针的时间顺序历史记录。我们了解到，引用日志就像是个人操作日记，它会记录提交、合并、变基等操作，即使是那些无法通过任何分支访问的提交也会被记录下来。我们分析了 git reflog 的输出，理解了其中的各个组成部分，如提交哈希、HEAD 指针、引用日志条目索引（例如 HEAD@{0}）以及所执行的操作。

接着，我们探讨了如何在引用日志中搜索特定的提交哈希，以确定某个特定的提交是否存在于引用日志历史中。最后，我们简要介绍了引用日志条目过期的概念，明白了引用日志条目并非永久保留，最终会被清理。本次实验展示了 git reflog 作为理解仓库历史和恢复可能丢失的工作的重要工具的强大功能。