如何使一个分支既集成了主模块中的更改，又集成了另一个分支，该分支是从老主分支中分离出来的？

Question

所以我在GitHub做了一次公关，后来被合并成了主人。现在，我有另一个PR，将需要一段时间来合并，并在第一个PR被合并之前已经从主人的分支。

现在我想做第三次公关，但它必须分支出最新的主人，也包括在第二次公关的变化，我提到了(一个将需要时间合并)。

我想我需要从大师的分支，然后重新基地的第二次公关的分支，在新的分支之上。不知道这是否是正确的方式，或如何准确地进行它。

如何整合最新版本的master，以及如何将未合并的分支转换为新的分支？

Answer 1

如何整合最新版本的master，以及如何将未合并的分支转换为新的分支？

最简单的办法就是在第二次公关中做一个新的分支，把主人和合并。

$ git checkout -b 3rdPR master
$ git merge 2ndPR

在第二次PR被合并为大师之后，再通过将主人合并到第三次PR来更新第三PR。

$ git checkout 3rdPR
$ git merge master

或者，将3 3rdPR重新建立在掌握的基础上。

$ git checkout 3rdPR
$ git rebase master

这将导致一个更干净的历史，而不需要所有中间更新合并。

更高级的事情是首先将你的第二次公关重新定位到大师身上。这是一个好主意，无论如何，这意味着第二次公关是最新的审查。然后，你可以简单地从第二次公关分支。

你有这个。

     G - H [2ndPR]
    /
A - B ----- F [master]
     \     /
      D - E

那就重新定位。

$ git checkout 2ndPR
$ git rebase master

              G1 - H1 [2ndPR]
             /
A - B ----- F [master]
     \     /
      D - E

(因为您已经按了2 2ndPR，所以需要强制推送更新。不要使用--force，使用git push --force-with-lease。在此解释。)

现在做一个分支机构2 2ndPR。

$ git checkout -b 3rdPR 2ndPR

              G1 - H1 [2ndPR][3rdPR]
             /
A - B ----- F [master]
     \     /
      D - E

还有一些关于3 3rdPR的工作。

                     J - K [3rdPR]
                    /
              G1 - H1 [2ndPR]
             /
A - B ----- F [master]
     \     /
      D - E

如果2 2ndPR被更新..。

                     J - K [3rdPR]
                    /
              G1 - H1 - L - M [2ndPR]
             /
A - B ----- F [master]
     \     /
      D - E

...you可以在2 2ndPR的基础上重新定位3 3rdPR。

$ git rebase 2ndPR
                              J1 - K1 [3rdPR]
                             /
              G1 - H1 - L - M [2ndPR]
             /
A - B ----- F [master]
     \     /
      D - E

当2 2ndPR被合并..。

                              J1 - K1 [3rdPR]
                             /
              G1 - H1 - L - M
             /               \
A - B ----- F --------------- N [master]
     \     /
      D - E

...rebase 3 3rdPR进入主站。

$ git rebase master
              G1 - H1 - L - M   J2 - K2 [3rdPR]
             /               \ /
A - B ----- F --------------- N [master]
     \     /
      D - E

这是比较复杂的，但是它会导致一个更受控的更新过程、更精确的QA和一个更干净的历史记录，不管您多久更新一次分支。它确实需要对能够可视化一个Git存储库的信心。

Answer 2

我想我需要从大师的分支，然后重新基地的第二次公关的分支，在新的分支之上。不知道这是否是正确的方式，或如何准确地进行它。

重新定位可能需要和合并一样长的时间，如果做得不对，可能会使事情变得更加困难。如果有疑问，不要重新定位，只需合并即可。如果出了什么问题，以后再撤销比较容易。

基本上，在您的例子中，要走的路是到分支PR2 (合并需要很长时间的分支)，创建一个名为PR3的新分支(您现在要处理的分支)，然后签出PR3，然后.将主服务器合并到PR3中。

嗯。我感觉到你的痛苦。这就像将PR2合并为master一样。但是最终您将不得不合并PR2来掌握。现在总比以后好。在大多数情况下，拖延的时间越长，冲突就越严重。

另外，您需要PR3从PR2和最近的主程序中进行更改。那你就得把它们合并。师父到PR2/3，PR2/3变成师父，没关系。即使您使用rebase，它也将以相同的冲突结束。这是因为您需要两个分支的内容，而一个分支的内容更改与另一个分支的内容更改冲突。如果您想要这两组更改，就必须解决这些冲突。

“避免”解决冲突的唯一方法是从最近的主服务器上启动PR3，然后手动遍历来自PR2的所有更改，然后在PR3上手动重新应用它们作为新的提交(因此在主服务器上，因为我们在主服务器上启动PR3 )。在完成此操作(意思是:将每个更改复制到每个文件并将其粘贴到正确的位置、提交、进行下一次更改等)之后，PR3将拥有最新的主服务器和来自PR2的更改.

实际上，...but是在做rebase-like的事情，只是手动的。你手动解决了所有的冲突。因此，您的结果是手动合并PR2->master，调用它PR3，然后不告诉git您合并了它，并解决了所有的问题。

所以。我是认真的。我建议：

• 在PR3上创建分支PR2
• 结帐PR3
• 将主机合并到PR3 //A中
• 解决冲突//B
• 提交//C
• 关于PR3的工作

作为一种奖励，A+B+C的结果是一位即将成为公共关系的候选人，名为“最终将PR2合并为主人”。

(还请注意，在上面的待办事项列表中，没有对PR2或master的一个更新。他们不动。如果A/B/C出现问题，只需删除PR3分支并重新开始)