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

Question

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

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

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

最好的方法是什么？棘手的部分是目前暂存/开发分支是私有的。听起来我必须公开一个开发分支，然后指导人们从该分支分支并将 PR 提交到该分支？

Answer 1

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

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

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

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

第二个问题是更重要的一个。如果 commitB与 commit 冲突G，那么无论您如何尝试从myfeatureinto获取更改develop，您都必须成为解决该冲突的人。这并不理想；我发现 PR 的作者比维护者更容易承担解决冲突的责任。

话虽如此，有两种解决方案：公开，或变基并合并。

上市

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

您提到您的develop分支中有某些私人文件。根据您需要这些文件的用途，您可能能够获取ignore它们，或者从中提取敏感值以在运行时加载。最好永远不要在存储库中的任何地方拥有私有文件，因为除其他原因外，您可能会意外公开develop。

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

变基和合并

如果你绝对不能公开develop，那么你需要rebase和merge。首先，执行以下操作：

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。