我有以下提交历史记录：
* c742f81 (HEAD -> new_feature) x8
* 1869290 x7
* 697809b x6
* a61e55c x5
|\
| * da890d6 (master) n6
| * ccc8f5e n5
| * 0095064 n4
| * 002ab13 n3
| * cb93dc4 m4
| * ccaa631 m3
* | 714da58 x4
* | ea11b0d x3
* | 66f1582 x2
* | 3e96100 x1
|/
* 4f46723 m2
* ce576e8 1
如您所见，我在master上有n6分支，在new_feature上有x8分支。我运行git rebase -i master new_feature，我得到了：
pick 3e96100 x1
pick 66f1582 x2
pick ea11b0d x3
pick 714da58 x4
pick 697809b x6
pick 1869290 x7
pick c742f81 x8
Rebase `da890d6..c742f81` onto `714da58` (7 commands)
现在，
为什么我得到714da58？它不应该是da890d6吗？
另外，x5在哪里（Git应该重新合并在x5中合并的提交）？
答案 0 :(得分：1)
在这种情况下，您已告诉Git采取的措施是将new_feature置于master之上并将其变基（重播）。 Git向您显示的是将放置在master顶部的提交。
在这种情况下，您看到x1到x4，因为它们在new_feature上，但不在master上，并且您告诉Git您想将所有此类提交重播到{ {1}}。您不会看到master，因为它不会被重新设置基础：它已经在master上了。您遗漏了n6，因为默认情况下x5不会重播合并。在这种情况下，这是有道理的，因为合并不会引入任何新内容。
但是，您可以根据需要使用git rebase的{{1}}选项来重新创建合并；这样做需要相对较新的Git版本。
您看到--rebase-merges条目，因为Git最终可能会使用reflog作为寻找更好的共同祖先的基础； git rebase选项中对此进行了说明。这并不总是产生“逻辑”听起来不错的落实，但通常确实会产生更好的基准。可能在某个时候，您的分支机构位于714da58，这对两个分支机构来说也不常见。
答案 1 :(得分：0)
现在，为什么我得到
714da58了？它不应该是da890d6吗？
是的，它将是da890d6。显示消息错误有bug in git，在某些情况下需要重新设置。
另外，x5在哪里（Git应该重新合并合并的提交 x5）？
当--rebase-merges中不使用git rebase选项时，任何合并提交都会扩展（例如此处x5是合并提交）将被删除，而n3，n4，n5，n6，m3和m4将被替换），而git会将这些提交放入单个线性分支（此处位于x4上方）。但是随后观察到，n3，n4，n5，n6，m3和m4都由master和new_feature共享。因此，new_feature..master不会选择git rebase -i master new_feature会选择它们。