如何使用GitHub Pull Requests做修補程序

Question

警告：我對git和GitHub都很新。

因此，在我目前的設置中，我的團隊使用git flow Hotfixes（通常由GitKraken或IntelliJ等圖形工具啟動和完成）進行更改，這些更改必須合並到兩個分支中並在兩個分支中向上推送。 例如，流程將是：

1. 從大師拉最新
2. 啟動修補程序
3. 提交更改
4. 將修補程序分支合並到主服務器中並開發並推送上游兩者

我們現在正在考慮將代碼移到GitHub中，並希望開始使用Pull Requests，原因如下：

• CI掛鈎運行測試和東西
• 放置代碼特定注釋的地方與底層“問題”沒有直接關系
• 避免每個人不斷地將最新的master / develop拉到他們的本地機器上，以便他們可以合並更改

但在Hotfixes的情況下，我不知道該怎么辦，因為我正在合並到兩個分支但它真的是一個“動作”所以手動創建兩個拉動請求似乎很奇怪，特別是因為我們當前的流程中的步驟4）單擊一下。

有一種聰明的方法來處理這個問題嗎？ 我理想的情況是推動Pull Request上的Merge按鈕只會合並到兩者中，但這似乎不是一個可用的選項。

Answer 1

正如您所提到的，Pull Request只有一個目標分支，因此您將無法通過合並一個Pull Request將修補程序推送到master和develop 。

我也很驚訝你提到你的步驟＃4 - 將修補程序分支合並到master和develop並向上游推送 - 是一個動作。 雖然很有可能從hotfix到master的合並不會遇到合並沖突，但我不能說從hotfix到develop的合並是相同的，因為自從上次部署到生產以來它可能已經工作。

我的建議如下：

• 從hotfix到master創建一個PR，並讓某人查看它以驗證修復
• 一旦它合並到master ，從hotfix創建另一個PR來develop並查看是否遇到合並沖突
  • 如果是這種情況，請解決合並沖突，以便PR最終處於要合並的狀態，並讓某人審核PR
  • 如果沒有合並沖突，那么讓某人審查PR

---

如果您真的想要沿着自動化路徑走下去，另一種解決方案是利用GitHub webhooks和API。

webhook將允許您在合並PR時收到通知 。 您可以檢查有效負載以確保基本分支以hotfix/開頭，並且目標分支是master 。 然后，您可以使用API​​從同一個hotfix分支創建新PR以進行develop從而對該事件作出反應。

它將涉及一些開發，並且努力可能不值得，因為通過UI創建PR仍然非常容易和快速。