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

【问题标题】：On Github, merging PR into different branch在 Github 上，将 PR 合并到不同的分支
【发布时间】：2017-03-21 11:59:37
【问题描述】：

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

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

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

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

【问题讨论】：

您应该定期将 master 合并到任何功能分支中。我不明白这里有什么问题。 master 应该是最新的 stable 分支。它并不总是最前沿的。只要 PR 看起来不错，有测试并且一切都通过了，就没有理由不合并到 master。
嗯，但是合并到开发分支而不是直接合并到主分支不是首选吗？您所说的类似于修补程序，对于大多数软件团队来说，这是不可取的。
你的开发分支不能公开有什么原因吗？
那里只有一堆相对私密的文件，理想情况下只有开发团队才能看到，而不是任何可以提交 PR 的人看到。但是，是的，否则，我可以将 dev 分支放在公共遥控器上。人们可以向那里提交 PR 而不是 master。
不，它没有。作为正常开发过程的一部分，特性分支一直被添加到 master 中，尤其是在大型团队中。如果您在合并公共分支机构之前没有针对您的公共分支机构审查 PR 的流程，那么您不应该让该分支机构接受来自公众的 PR。如果您的测试不够好，或者您的 CI 流程不好或不存在，您需要先修复它。

标签： git github git-merge pull-request

【解决方案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 的作者比维护者更容易承担解决冲突的责任。

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

公开

这是我推荐的解决方案，因为它将是最简单的长期解决方案。您可以将您的 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 的新更改。

【讨论】：