在團隊中限制Gitflow發布分支

Question

我很高興能找到關於我的准備的全面答案。 就這個：

在我的團隊中，我們使用gitflow作為開發和發布項目的工作流程。 現在我們遇到了gitflow的概念問題。

當我們決定發布時，我們將我們的工作推向發布分支，QA和客戶通過一組錯誤或當前功能的更改請求來測試代碼和響應（沒有像gitflow建議的新功能）。

問題是當我們想要修復錯誤時，因為我們需要以團隊的形式工作，許多人應該在同一個發布分支上工作。 因此，要么我們通過工作來面對沖突問題，要么我們必須努力工作才能完成工作。

我們有了從發布創建新分支並在這些分支上並行工作的想法，但我們仍然覺得這不是最好的方法。

讓團隊在發布分支上並行修復錯誤的最佳方法是什么？

Answer 1

這里顯然沒有對錯，但我建議您讓QA和客戶測試功能分支獨立。 這樣，每個測試會話的范圍將更小，更容易處理，您可以解決任何問題，而不會與其他分支沖突。 一旦您的分支經過測試和修復，您就可以將其移至發布分支。

Answer 2

這可能不是您正在尋找的答案，但對我而言，git流程方法的一個重要部分是所有內容都是分支和合並的（通過某種審核流程/拉取請求）。

出於這個原因，我絕對建議你分支你的發布分支並合並回它。 不分支的一個明顯的缺點是，沒有人進行提取和檢查，你沒有執行審查（如拉取請求）的步驟，此時提交已經在你的發布分支中（糟糕！）。 此外，你可以讓兩個人同時提交和推送等等。

說了這么多，我知道這可能不是與git的流動過程完全貼合在特性和錯誤修正從分支develop ，從版本develop和修補程序master ，但你也應該記住，git的流動實際上只是一個概念，適應的指南和心態。 它的命令行工具只是為了幫助你。

例如，在我目前的工作中，我們開始嘗試使用git flow的純度（我們有一個類似的聲音場景給你），並發現我們最終使用了概念但是自己管理分支並在GitHub拉取請求中合並而不是您的標准git flow feature finish類型方案。 我們這樣做的主要原因是避免多個開發人員同時完成和推送功能 。

我希望這可以幫助你。