在git中，* 分支并不真正存在 * --也就是说，分支并不像其他系统中那样是“一系列带有标签的提交”。相反，分支指向一个 * 单一的提交 *，位于分支的“尖端”，git通过 * 向后 * 遍历每个提交的“父提交”来查找历史记录。“分支X上的提交”更准确地称为“从标记为X的尖端可到达的提交”。
这是因为当你发出合并请求来合并“feature-X上的所有内容到main“时，git会尝试合并 * 所有从feature-X可以到达，但从main无法到达的提交。通常，这是一个识别“为特性X开发的提交”的好方法，因为提交图看起来像这样：

-- C <-- D <-(feature-X)
               /
... <-- A <-- B <-(main)
               \
                -- E <-- F <-(feature-Y)

feature-X的PR将选择提交C和D，而feature-Y的PR将选择提交E和F。
但是如果你把一个分支“rebase”到另一个分支上，你最终得到的图会更像这样：

... <-- A <-- B <-(main)
               \
                -- E <-- F <-(feature-Y)
                          \
                           -- C2 <-- D2 <-(feature-X)

如果feature-Y没有被合并，并且你为feature-X设置了PR，git会在D2（feature-X）的历史记录中查找所有没有出现在B（main）历史记录中的提交，并找到 E，F，C2，和D2。
这可能是有道理的：你需要你的同事已经完成的工作，所以需要以某种方式合并进来。另一方面，如果feature-Y被放弃，在那些提交中可能有你 * 不 * 想要的东西--也许你真的想要F而不是E;如果是这样，您将需要创建一个不同版本，并基于该版本进行重定基：

-- F2 <-- C3 <-- D3 <-(feature-X)
               /
... <-- A <-- B <-(main)
               \
                -- E <-- F <-(feature-Y, abandoned)

如果feature-Y先被合并，只要feature-Y没有被重定基或“压缩”，一切都很好;你会得到一个像这样的图

... <-- A <-- B <--------- M <-(main)
               \          /
                -- E <-- F <-(feature-Y)
                          \
                           -- C2 <-- D2 <-(feature-X)

现在git会在D2（feature-X）的历史记录中查找所有M（main）历史记录中没有的提交，并且只会发现C2和D2 - E和F已经在M的历史记录中。