Question

假设我们有

C1--C2--C3--C6--C7   <- topic, HEAD
 \   \     /
  \  C4--C5      
   \
    C8--C9           <- master

（我们添加了一个空的file1并提交给C1，添加了一个空的file2并提交给C2，依此类推。）

然后我们这样做：

$ git rebase master

结果是：

C1--C8--C9                         <- master
         \
         C4'--C2'--C5'--C3'--C7'   <- topic, HEAD

我已经创建了一个自动bash脚本here，可以根据需要进行测试。

正如我从chapter 3.6 in git-scm.com book中学到的，Git跳过了合并结果C6，因此这里没有显示C6'。

我的问题是，Git使用哪个顺序从topic分支中挑选樱桃？为什么结果是...-C4'--C2'--C5'--C3'--C7'而不是...-C2'--C3'--C4'--C5'--C7'（按时间顺序）？

Answer 1

（顺便说一句，感谢您的复制脚本，在这里非常有帮助。）

过去的顺序有所不同，但通常是通过运行git rev-list（git log的姊妹命令，默认情况下仅生成哈希ID）生成的。由于哈希ID对于人类来说很困难，因此通常更容易使用git log来查看顺序。

在这种情况下，订单来自：

$ git log --oneline --reverse --no-merges master..topic
5ff52aa C4
aefbb19 C2
0363c27 C5
90aaf5d C3
f953082 (topic) C7

但是，如果我们添加--topo-order（git rebase在各种旧版Git版本中所做的操作），则会得到：

$ git log --oneline --reverse --topo-order --no-merges master..topic
aefbb19 C2
90aaf5d C3
5ff52aa C4
0363c27 C5
f953082 (topic) C7

在有多个活动提交可供选择的情况下，实际顺序基于提交时间戳。也就是说，Git正在从尖端提交向后进行修订。每当合并时，Git都会将所有父级放入优先级队列，从而增加要访问的提交数。优先级队列的默认排序顺序基于提交者时间戳。由于git rebase没有设置任何其他优先级，因此将使用该优先级。

（新的，非拓扑排序的顺序是新的git rebase--helper内部命令的结果，该内部命令首先出现在Git版本2.13中。合并“ preserving”（确实），是重新创建— git rebase -p的变体仍使用拓扑排序。标记为git rebase -r的新奇样式不需要拓扑排序。）