在Github上，將PR合並到其他分支

Question

假設有人在Github上向公共/管理員提交了PR。

有沒有辦法將該PR合並到另一個分支中？ 否則，看起來我必須合並到public / master中，然后將其向后合並到development / staging分支中。 這就像讓人們進行修補程序然后將修補程序合並到開發分支中一樣，這是我們通常應該避免的事情，對吧？

讓人們跟蹤PR並將其提交到階段/開發分支而不是母版似乎更有意義。

最好的方法是什么？ 棘手的部分是當前的暫存/開發分支是私有的。 聽起來我必須公開一個開發分支，然后引導人們從該分支分支並將PR提交給該分支？

Answer 1

根據定義，您無法將PR定位為您不知道存在的分支。

您的歷史記錄可能如下所示：

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

這里有兩個問題。 （1）對於PR myfeature不能定位develop ，因為develop是私有的，並且筆者不可見myfeature 。 （2） develop分支有一些提交（在本例中為B和C ）也是私有的。

第二個問題是更重要的一個。 如果提交B與提交G發生沖突，那么無論您如何嘗試將更改從myfeature轉變為develop ， 您都必須成為解決該沖突的人。 這不理想； 我發現，PR的作者而不是維護者更容易解決沖突。

話雖這么說，但有兩種解決方案：公開上市，或重新設定基礎並合並。

公開

這是我推薦的解決方案，因為它將是最簡單的長期解決方案。 你可以把你的develop分支GitHub上並予以公布。 這將允許其他用戶從develop分支並針對它發送PR。

您提到您的develop分支中有某些專用文件。 根據您需要這些文件的用途，您可以ignore它們，或從中提取敏感值以在運行時加載。 最好不要在回購中的任何地方放置私有文件，因為除其他原因外，您可能會意外地將develop公開。

如果您使用此解決方案，那么您已經非常接近使用Git Flow工作流程，我也建議您使用它。

變基並合並

如果您絕對不能公開develop ，則需要重新設置基礎並合並。 首先，請執行以下操作：

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新更改。