`git rebase` 使用什么顺序从合并的分支中挑选提交来进行 cherry-pick 操作？

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脚本 在这里，如果您想要测试它，可以使用。

从git-scm.com书中的第3.6章中学到，Git跳过了合并结果C6，因此这里没有展示C6'。

我的问题是，Git从topic分支中使用的顺序是什么？为什么结果是...-C4'--C2'--C5'--C3'--C7'而不是按时间顺序排列的...-C2'--C3'--C4'--C5'--C7'？

- Phuc

---

你可以尝试使用 git rebase --preserve-merge master 命令来代替吗？(https://dev59.com/WWUo5IYBdhLWcg3wmQZN#50555740) - VonC

可能有帮助：如何为Git rebase选择合并策略？ - Tim Biegeleisen

Answer 1

顺便说一句，感谢您提供的脚本，这对我们非常有帮助。

过去顺序可能有所不同，但通常是通过运行git rev-list（默认情况下仅生成哈希ID的姐妹命令git log）来生成。由于哈希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版本中的git rebase所做的，我们会得到以下结果：

$ 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中。保留合并（实际上是重新创建）的git rebase -p变体仍然使用拓扑排序。新的标记git rebase -r不需要拓扑排序。

- torek

---

在阅读了您的答案后，我进行了一些测试，直到这个测试，我认为我理解了您的答案，并解决了我的主要问题。非常感谢您，您的答案对我非常有帮助！ - Phuc