在 Github，将 PR 合并到不同的分支

Question

假设有人在 Github 向 public/master 提交了 PR。

有没有办法将该 PR 合并到不同的分支？否则，看起来我必须合并到 public/master，然后将其向后合并到 development/staging 分支。这就像让人们做一个修补程序，然后将修补程序合并到一个开发分支中，这是我们通常应该避免的事情吧？

似乎让人们跟踪 PR 并将其提交到 staging/development 分支而不是 master 更有意义。

最好的方法是什么？棘手的部分是目前 staging/development 分支是私有的。听起来我必须创建一个开发分支 public，然后指导人们从该分支分支并向该分支提交 PR？

Answer 1

根据定义，您不能将 PR 定位到您不知道存在的分支。

您的历史记录可能如下所示：

*--A--B--C [develop] (private)
    \
 ... D--*--*--E [master]
               \
                F--G--H--I [myfeature] (PR for this)

这里有两个问题。 (1) myfeature 的 PR 不能针对 develop，因为 develop 是私有的，对 myfeature 的作者不可见。 (2) develop 分支有一些提交（在本例中为 B 和 C）也是私有的。

第二个问题比较重要。如果提交 B 与提交 G 冲突，那么无论您如何尝试将更改从 myfeature 获取到 develop，您必须是解决冲突的人。这并不理想；我发现 PR 的作者比维护者更容易承担解决冲突的责任。

话虽如此，有两种解决方案：转到 public，或者变基并合并。

去Public

这是我推荐的解决方案，因为它将是最简单的长期解决方案。您可以将 develop 分支推送到 GitHub 并使其成为 public。这将允许其他用户从 develop 分支并针对它发送 PR。

您提到您的 develop 分支中有某些私人文件。根据您需要这些文件的用途，您可以 ignore 它们，或从中提取敏感值以在运行时加载。最好永远不要在你的 repo 中的任何地方有私人文件，因为除其他原因外，你可能会不小心制作 develop public.

如果您使用此解决方案，那么您已经非常接近使用 Git Flow 工作流程，我也推荐它。

变基并合并

如果你绝对做不到developpublic，那你就需要rebase合并了。首先，做：

git rebase --onto develop master myfeature

您的历史记录现在将如下所示：

           F'--G'--H'--I' [myfeature]
          /
*--A--B--C [develop]
    \
 ... D--*--*--E [master]
               \
                F--G--H--I

然后您可以正常合并到 develop：

git checkout develop
git merge --no-ff myfeature

给你：

           F'--G'--H'--I' [myfeature]
          /             \
*--A--B--C---------------J [develop]
    \
 ... D--*--*--E [master]
               \
                F--G--H--I

此解决方案的另一个缺点是，就 GitHub 而言，PR 尚未合并，因此您必须手动将其关闭。与此相关，提交 PR 的用户将无法看到它已被合并，直到您发布从 develop 到 master 的新更改。

在 Github，将 PR 合并到不同的分支

On Github, merging PR into different branch

git

github

git-merge

pull-request

去Public

变基并合并