如何创建一个将 master 中的更改和从旧 master 分支出来的另一个分支中的更改都集成在一起的分支？

Question

所以我在 GitHub 上做了一个 PR 合并到 master。 现在我有另一个 PR 需要一些时间来合并并且在第一个 PR 合并之前从 master 分支。

现在我想处理第三个 PR，但它必须从最新的 master 分支出来，并且还包括我提到的第二个 PR 中所做的更改（需要时间来合并）。

我想我需要从 master 分支，然后在新分支的顶部重新建立第二个 PR 的分支。 不确定这是否是正确的方法，或者如何准确地去做。

如何将最新版本的 master 以及未合并分支的更改集成到新分支中？

Answer 1

如何将最新版本的 master 以及未合并分支的更改集成到新分支中？

最简单的事情是在第二个 PR 中创建一个新的分支和合并。

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

在第二个 PR 合并到 master 后，通过再次合并 master 到第三个 PR 来更新第三个 PR。

$ git checkout 3rdPR
$ git merge master

或者，将 3rdPR 重新设置在 master 之上。

$ git checkout 3rdPR
$ git rebase master

这将导致没有所有中间更新合并的更清晰的历史记录。

---

更高级的做法是首先将您的第二个 PR 重新设置为 master。 无论如何，这是一个好主意，这意味着第二个 PR 在审查期间是最新的。 然后你可以简单地分支出第二个 PR。

你有这个。

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

然后重新定位。

$ git checkout 2ndPR
$ git rebase master

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

（因为你已经推送了 2ndPR，你需要强制推送更新。不要使用--force ，使用git push --force-with-lease 。解释在这里。）

现在在 2ndPR 上创建一个分支。

$ git checkout -b 3rdPR 2ndPR

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

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

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

如果 2ndPR 更新...

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

...您可以再次在 2ndPR 之上重新设置 3rdPR。

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

当 2ndPR 合并时...

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

...将 3rdPR 重新设置为 master。

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

这更复杂，但无论您更新分支的频率如何，它都会导致更可控的更新过程、更准确的 QA 和更清晰的历史记录。 它确实需要对能够可视化 Git 存储库的信心。

Answer 2

我想我需要从 master 分支，然后在新分支的顶部重新建立第二个 PR 的分支。 不确定这是否是正确的方法，或者如何准确地去做。

重新定位它可能需要与合并它一样长的时间，并且如果操作不当可能会使事情变得更加困难。 如果有疑问，不要变基，只需合并。 如果出现问题，以后更容易撤消。

基本上，在您的情况下，要走的路（恕我直言）是转到分支 PR2（需要很长时间才能合并的分支），创建一个名为 PR3 的新分支（您现在将处理的分支），然后结帐 PR3，然后......将master合并到PR3中。

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

此外，您需要 PR3 对 PR2 和最新的主版本进行更改...然后您需要合并它们。 master转PR2/3，PR2/3转master，无所谓。 即使你rebase ，它仍然会以相同的冲突结束。 这是因为您需要来自两个分支的内容，并且来自一个分支的内容更改与来自另一个分支的内容更改冲突。 如果您想要两组更改，则必须解决冲突。

“摆脱”解决冲突的唯一方法是从最近的 master 启动 PR3，然后手动遍历 PR2 中的所有更改并手动重新应用它们作为 PR3 上的新提交（因此在 master 上，因为我们启动 PR3在这个练习中的主人）。 执行此操作后（意思是：将每个更改复制到每个文件并将其粘贴到正确的位置，提交，进行下一个更改等），您最终将获得 PR3 拥有最新的母版和来自 PR2 的更改...

...但实际上，您所做的只是手动进行了类似rebase的操作。 而且您手动解决了所有冲突。 所以你最终手动合并了 PR2->master，称之为 PR3，然后没有告诉 git 你合并了它并解决了所有问题。

所以。 严重地。 我建议：

• 在 PR2 上创建分支 PR3
• 结帐 PR3
• 将 master 合并到 PR3 //A
• 解决冲突 //B
• 提交 //C
• 在 PR3 上工作

作为奖励，A+B+C 的结果是一个准备好的 PR 候选者，称为“finally merge PR2 into master”

（还要注意，在上面的待办事项列表中，PR2 或 master 没有一个更新。它们保持不变。如果 A/B/C 出现问题，只需删除 PR3 分支并重新开始）