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

TD；DR:过去的PR中的代码在新的PR被批准之前没有得到批准，这到底会发生什么

我有几个公关与我的主要分支“发展”合并时有冲突：

关于“开发”，我有c1、c2、c3等。考虑到我的PR从文件1导致冲突在文件A和B。我的特征2导致冲突仅在文件C。让我们假设，为了修复特征2 PR，开发人员创建了一个新的分支从开发，拉功能2的内容，并提交到PR也（让我们称之为PR 3）与正确的决定，从A和B，除了所有其他功能2文件。当这个较新的PR 3被批准时，功能2 PR也被自动批准。功能1中的冲突PR会发生什么变化

---

它不能再合并到过去的提交中，除了来自develop的HEAD。它的源代码没有添加到功能2 PR上，也没有添加到功能3 PR上。根据一些个人经验，我认为在这种情况下，feature 1 PR看起来是合并的，但实际上C3上甚至没有一个文件出现。

我想你的问题有点混乱

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

=>所以两个分支都应该指向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上点击merge时，您将创建一个包含E、F、G的commit C5。因此在development分支中，您有E、F对应于Feature2 PR2+G PR3这就是为什么bitbucket可以自动告诉PR2是merge。根据您的版本，但如果仔细阅读PR2，bitbucket将告诉您这是与PR3合并

那么PR1呢？现在您处于这种情况：

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

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