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

假设有人在Github上向公共/主机提交PR

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

让人们跟踪并将PRs提交给登台/开发分支而不是主分支似乎更有意义

---

最好的方法是什么？棘手的部分是，目前阶段/开发分支是私有的。听起来我必须公开一个开发分支机构，然后指导人们从该分支机构获得分支机构并向该分支机构提交PRs？

根据定义，您不能针对您不知道存在的分支机构制定PR

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

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

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

这里有两个问题。（1）

myfeature

的PR不能针对

develope

，因为

develope

是私有的，对

myfeature

的作者不可见。（2）

develope

分支有一些提交（在本例中是

B

和

C

）也是私有的

第二个问题更重要。如果commit

B

与commit

G

冲突，那么无论您如何尝试将

myfeature

更改为

develop

，都必须由您来解决该冲突。这并不理想；我发现PR的作者比维护者更容易承担解决冲突的责任

话虽如此，有两种解决方案：上市，或重新设定基础并合并

上市 这是我推荐的解决方案，因为这将是最简单的长期解决方案。您可以将您的

development

分支推送到GitHub并将其公开。这将允许其他用户从

分支开发
，并针对它发送PRs

您提到在
develope
分支中有某些私有文件。根据您需要这些文件的目的，您可以
忽略它们，或者从中提取敏感值以在运行时加载。最好不要在回购协议的任何地方有私人文件，因为除其他原因外，您可能会意外地将
develope
公开

如果您使用这个解决方案，那么您已经非常接近使用工作流了，我也推荐使用工作流

重设基础和合并
如果您绝对不能将
develope
公开，那么您需要重新设置基础并合并。首先，做：

git rebase --onto develop master myfeature

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

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

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

然后，您可以像往常一样合并到
developer
：

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的用户将无法看到它已被合并，直到您发布从
develope
到
master
的新更改。您应该定期将master合并到任何功能分支。我不明白这里有什么问题
master
应该是最新的稳定分支。它并不总是最前沿的。只要PR看起来不错，有测试，一切都通过了，就没有理由不合并到master。呃，但是合并到开发分支而不是直接合并到master中不是更好吗？您所说的类似于修补程序，这对大多数软件团队来说并不可取。您的开发分支机构不能公开有什么原因吗？那里只有一堆相对私有的文件，理想情况下只有开发团队才能看到，而不仅仅是任何可以提交PR的人。但是，是的，否则，我可以把开发分支放在公共远程上。人们可以将PRs提交给它，而不是提交给master。不，不是这样。特性分支始终作为正常开发过程的一部分添加到master中，尤其是在大型团队中。如果在合并公共分支机构之前，您没有审查公共分支机构公共关系的流程，那么您不应该让该分支机构接受公共关系。如果您的测试不够好，或者您的CI流程不好，或者不存在，那么您需要首先解决这个问题。