代码之家  ›  专栏  ›  技术社区  ›  gabriel119435

当一个新的pr合并到同一个分支上时,为什么bitback会忽略以前的pr?

  •  2
  • gabriel119435  · 技术社区  · 6 年前

    DR: 以前的pr代码在新的pr之前没有得到批准,这到底是怎么回事?

    我有几家公关公司试图与我的主要分支机构“开发”合并:

    enter image description here

    关于“开发”,我已经提交了c1、c2、c3等等。考虑到功能1的pr导致了文件a和b的冲突。我的功能2只导致了文件c的冲突。让我们假设,为了修复功能2的pr,开发人员从develop创建了一个新的分支,提取了功能2的内容,并将其提交到pr中(我们称之为pr 3),使用正确的A和B的决定,除了所有其他功能2文件。当新的pr 3被批准时,功能2 pr也被自动批准。与功能1冲突的pr会发生什么?

    除了开发主管之外,它不能再合并为过去的提交。它的源代码没有添加到功能2pr中,也没有添加到功能3pr中。根据一些个人经验,我认为在这种情况下,功能1pr看起来是合并的,但实际上在c3中甚至没有一个文件。

    1 回复  |  直到 6 年前
        1
  •  1
  •   user43968    6 年前

    我想你的问题有点困惑。

    首先,您的图片错误,请求合并 分支 在另一个分支中,开发分支:

    =>因此,两个分支都应指向由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。因此,在develop分支中,您拥有e,f对应于feature2 pr2+g pr3,这就是为什么bitback可以自动地告诉pr2是merge。 取决于您的版本,但是如果您仔细阅读pr2,bitback会告诉您这是与pr3合并的。

    那么,pr1发生了什么?现在您处于这种情况:

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

    也许所有的冲突都消失了,也许没有,但Bitback不会为你忽略/合并任何东西。