是否有一個gitflow流程用於分支和錯誤修復與發佈分支？

Question

爲了確保所有代碼最終都能通過拉取請求代碼審查，我們已開始在git-flow style之後創建關於功能和bug分支的分支。

唯一的問題是，一旦在發佈分支中發現了一個錯誤，我們通常必須從發佈分支中創建一個分支，以便向發佈分支返回一個請求。但是，在修復發行版分支的錯誤時，似乎沒有一個明顯的git-flow過程來處理分支版本分支。

什麼是修復發佈分支bug和代碼審查的git流程？

您是否應該修復開發中的錯誤並創建新的發佈分支？ 分支仍然有效的git-flow發佈分支？ 處理髮布分支bug修復的pull請求代碼評論的最佳方式是什麼？

Answer 1

我處理它的方式是從發佈分支關閉修補程序分支。修復bug後，我將合併到master/release分支，併合併到Dev分支，然後再分支到其他功能。

然後該修復程序將被刪除，因爲它將被記錄在master或dev中。

Answer 2

錯誤修復分支應該從主分支（或任何分支代表您的生產代碼）分支。如果你正在使用git flow，這有時意味着如果你已經在一個分支上修改了代碼，那麼你必須選擇提交bug修復分支。

Answer 3

我剛剛來過這個相同的問題。我建議從發佈分支創建一個正常的分支。在那裏進行修復併爲該分支創建一個合併到發佈分支的請求。這是使用正常的分支和合並命令，而不是Git Flow命令。

步驟的細節在下面：

1. 結帳釋放/ 2017年5月24日的分支。其中2017.05.24是發佈分支的名稱。
2. 執行分支命令並將其命名爲「release2017.05.24 - 修復原因」。這將明確爲什麼分支存在（用於發佈修復）。
3. 進行更改，提交併將更改推送到服務器（將分支推送到原始位置）。
4. 在你的服務器上爲你的分支創建一個合併到release/2017.05.24分支的請求。注意：合併到發佈/ 2017.05.24分支不是默認值，因此請確保在創建拉取請求之前對其進行更改。
5. 關於代碼審查批准結帳「release/2017.05.24」
6. 執行合併命令，在「release2017.05.24 -reason for fix」分支中選擇您的提交。
7. 刪除本地和遠程分支機構爲貴「的release2017.05.24 - 原因修復」分支

希望這將更好地工作。 Git-flow命令集中有很多步驟和剎車，但應該允許發生拉取請求。