为什么当新 PR 合并到同一个分支时，BitBucket 会忽略以前的 PR？答案

【问题标题】：Why BitBucket ignores previous PR when a new PR is merged on the same branch?为什么当新 PR 合并到同一个分支时，BitBucket 会忽略以前的 PR？
【发布时间】：2018-08-14 18:40:01
【问题描述】：

TD;DR：过去 PR 的代码在新的 PR 获得批准之前没有得到批准，究竟会发生什么？

我有几个 PR 试图与我的名为“develop”的主分支合并：

在“开发”上，我提交了 c1、c2、c3 等。考虑我的特性 1 的 PR 导致文件 A 和 B 的冲突。我的特性 2 只导致文件 C 的冲突。假设为了修复特性 2 PR，开发人员从开发创建了一个新分支，提取特性 2 内容并提交除了所有其他功能 2 文件之外，还包含 A 和 B 的正确决定进入 PR（我们称之为 PR 3）。当这个更新的 PR 3 被批准时，特性 2 PR 也被自动批准。来自功能 1 的冲突 PR 会发生什么？

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

【问题讨论】：

标签： git bitbucket pull-request

【解决方案1】：

我想你的问题有点混乱。

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

=>所以两个分支都应该指向一个“虚拟”c5，结果是 c4 与 feature1 合并或 c4 与 feature2 合并

其次，我想您是在谈论 merge 而不是批准。 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 不会为你忽略/合并任何东西。

【讨论】：