如何签出到 Git 分支的某个时间点（即提交）？

Question

我想将我的 Git 分支回滚到特定的提交。因此，我运行 git log 并找到提交 SHA 哈希值，然后运行 ​​git checkout。

这通常工作得很好，但这次有些可疑。当我再次查看 git log 时，我发现最新的提交是正确的，但我错过了很多下面的提交。我突然意识到：此提交是另一个分支（另一个）合并的一部分，并且我看到了该分支的历史记录（预合并）。

master's log, pre-merge:        D-C-----B'-B-A-----F
another's log:              7-6-----5-4--------3-2-F
master's log, post-merge: M-7-6-D-C-5-4-B'-B-A-3-2-F

我签出提交 5 并从 another 获取历史记录中的提交：

5-4-3-2-F

但我想要历史记录中来自 master 的提交，post-合并：

5-4-B'-B-A-3-2-F

我已经制作了 一个存储库，您可以在其中测试它：

$ git clone git://github.com/henrik242/Git-Branch-Test.git
$ cd Git-Branch-Test
$ git checkout -t origin/another
$ git log  ## The commits are named "test [2-7]"
$ git checkout master
$ git log  ## master's original commits are named "test [A-D]".  
$ git checkout 68c1226a0c  ## test 5 
$ git log  ## We now have the commits in the history from the "another" branch,
           ## even though this commit exists in the "master" branch as well

我几乎可以使用 <代码>git rebase -i 做我想做的事：

$ git branch back-in-time
$ git checkout back-in-time
$ git rebase -i 18b1a648bc  ## the SHA1 of 'test 4', the commit before 'test 5'

生成一个编辑器：删除不需要的提交。保存并退出，git log 现在显示所需的提交：

5-4-B'-B-A-3-2-F

问题是 git rebase -i 不按与 git 相同的顺序显示提交log，这使得很难选择正确的提交。

Answer 1

合并不会混合提交，它只是加入 @Jefromi 的答案中描述的分支。因此，当然，您可以在任何给定时间恢复树的状态，但如果时间是在合并之前，您将需要小心选择正确的分支。所以，我想你应该使用 git log --oneline --graph ，这样你就可以在给定时间选择相应分支上的最新提交。当您检查该提交时，它显然只会有给定时间该分支的提交历史记录。

如果您想真正混合来自两个分支的提交，则需要一个使用 gitcherry-pick 或 git rebase -i 来对两个分支的提交进行排序的工作流程按时间顺序分支成直分支。这会带来各种各样的问题，至少是大量的合并冲突。此外，中间状态很可能在语义上不一致。

Answer 2

我不能说太多次：你所要求的历史从未存在过。如果您想手动创建它，但根本没有类似的东西可供您查看。合并不会以任何方式将提交混合在一起形成某种合并的历史。如果您的问题是“我如何手动创建这样的历史记录”，那么就问这个问题。但你似乎已经知道如何使用 rebase 了。

我认为您的主要误解可能是 git-log 的输出。 git log 显示的提交顺序本质上是任意选择。历史不是线性的，但它必须将它们一一列出，所以它确实如此。该顺序并不意味着一个提交是前一个提交的父级，因此这并不意味着如果您检查其中一个提交，您将在其下方打印所有内容的并集。它可能会打印提交列表，就像您在问题中放入的那样，但在您的示例存储库中，这就是历史记录的样子。您可以使用 gitk --all 或 git log --graph 来查看它。

1 - 2 - 3 - 4 - 5 - 6 - 7 (another-branch)
 \                       \
  A - B - C - D - --------M (master)

就是这样。合并不会神奇地将这些分支混在一起。它创建一个单个提交，其父级是合并提交，包含合并提交内容的组合。所以你可以检查提交2，或者提交B，但是没有“master分支中的提交2”。如果您愿意，您可以查看提交 B 并合并提交 2，看看会得到什么。

据我所知，你所说的你想要的提交列表就是通过合并提交 5 和 B 并以任意方式将其展平而得到的。如果您只想要合并的结果：

git checkout -b foo <commit-5>
git merge <commit-B>

如果您实际上想要这样的平坦历史记录：

git checkout -b foo <commit-5>
git rebase -i <commit-B>
# reorder them however it is you wanted them

但这些都是用户决定。您正在创建一个从未存在过的存储库状态。因为它从未存在过，所以你必须创建它。

---

至于评论中关于哈希的讨论，再次强调，SHA1 唯一标识一次提交。提交 2 的 SHA1 仅适用于该提交。你没有证明我的测试仓库是错的，你已经证明我是对的：那里只有一个提交 2，并且它只有一个哈希值。

提交是一个包含以下内容的对象：元数据（作者/提交者姓名、电子邮件、日期；提交消息）、对其父级的引用以及它所代表的树（将其视为内容的快照） 。因此提交 2 代表该特定快照。不多不少。它的父级是提交 1。这不是时间戳问题；而是提交 1。提交通过 SHA1 知道其父项。无论如何，提交 2 的父级都是提交 1。只有一个提交 2，无论你是从 master 分支还是其他分支到达它 - 看图，你可以看到它在 master 分支中的情况，通过 7、6、5、4、3。

Answer 3

我只回答我自己的问题：为了让这个工作流程正常工作（并具有某种意义），我必须使用 git log 的拓扑排序：git log --topo-order。这样，日志看起来像这样：

master's log, pre-merge:                D-C-B'-B-A-F
another's log:              7-6-5-4-3-2------------F
master's log, post-merge: M-7-6-5-4-3-2-D-C-B'-B-A-F

现在 git rebase -i 中的顺序是有意义的，因为它也是拓扑顺序的。只需剪掉底部的提交，直到到达有问题的提交并保存，瞧！

（顺便说一句，我首先需要这个工作流程，因为我试图查明哪个提交引入了错误。后来我意识到 git bisect 在这方面比我做得更好。）