为什么在同一个分支上合并新的 PR 时 BitBucket 会忽略之前的 PR？

Question

TD;DR: 旧 PR 的代码在新的 PR 获得批准之前到底发生了什么？

我有几个 PR 试图与我的主要分支 "develop" 合并时发生冲突：

在 "develop"，我提交了 c1、c2、c3 等等。考虑我的特性 1 的 PR 在文件 A 和 B 中导致冲突。我的特性 2 导致仅在文件 C 中发生冲突。假设，为了修复特性 2 PR，开发人员从 develop 创建了一个新分支，提取了特性 2 的内容并提交除了所有其他功能 2 文件之外，A 和 B 的正确决定也进入 PR（让我们称之为 PR 3）。当这个较新的 PR 3 获得批准时，功能 2 PR 也自动获得批准。来自功能 1 的冲突 PR 会怎样？

除了来自开发的 HEAD 之外，它不能再合并到过去的提交中。它的源代码既没有添加到功能 2 PR 上，也没有添加到 PR 3 上。根据一些个人经验，我认为在那种情况下功能 1 PR 显示为已合并，但实际上 C3 甚至没有一个文件。

Answer 1

我想你的问题有点混乱。

首先你的图片是错误的，拉取请求要求合并一个分支与另一个开发分支：

=>因此，两个分支都应指向 "virtual" c4 结果 c4 与 feature1 合并或 c4 与 feature2 合并

其次，我想您是在谈论合并而不是批准。 Bitbucket 本身不批准任何东西它会很棒 ;)

所以让我们回顾一下真实的图表是：

  A---------B---------C Feature1 (PR1)
 /                      \
c0--C1---C2---C2---C3---C4---(C5) develop
           \                /
             E---F-----------Feature2 (PR2)
                  \       /
                    G---- PR3

因此，当您在 PR3 上点击合并时，您创建了一个包含 E、F、G 的提交 C5。因此在开发分支中，您有 E、F 对应于 Feature2 PR2 + G PR3 这就是为什么 bitbucket 可以自动告诉 PR2 是合并。 取决于您的版本，但如果您仔细阅读 PR2，bitbucket 会告诉您它与 PR3 合并。

那么 PR1 发生了什么？现在你处于这种情况:

  A---------------B-------------C Feature1 (PR1)
 /                                \                 
c0--C1---C2---C2---C3---C4---C5---(C6) develop

也许所有的冲突都消失了，也许没有，但 bitbucket 不会 ignore/merge 为你做任何事情。

为什么在同一个分支上合并新的 PR 时 BitBucket 会忽略之前的 PR？

Why BitBucket ignores previous PR when a new PR is merged on the same branch?

git

bitbucket

pull-request