当在同一分支上合并新的PR时，为什么BitBucket忽略先前的PR？

Question

TD; DR：过去PR的代码在更新版本之前未得到批准会发生什么？

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

在“ 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甚至没有单个文件。

Answer 1

我想你的问题有点混乱。

首先，您的图片是错误的，一个拉取请求要求将分支与其他合并到此处的develop分支：

=>因此，两个分支都应指向由c4与feature1合并或c4与feature2合并导致的“虚拟” c5

第二，我想您是在谈论合并而不是批准。 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。因此，在develop分支中，您具有对应于Feature2 PR2 + G PR3的E，F。这就是为什么bitbucket可以自动告诉PR2正在合并的原因。 取决于您的版本，但如果您仔细阅读PR2，bitbucket会告诉您该文件已与PR3合并。

那么PR1会怎样？现在您处于这种情况：

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

也许所有的冲突都消失了，但bitbucket不会为您忽略/合并任何内容。