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

Question

為了確保所有代碼最終都通過pull請求代碼審查，我們已經開始按照git-flow風格創建功能和bug分支的分支。

唯一的問題是，一旦在發布分支中發現錯誤，我們通常必須從發布分支創建一個分支，以便將pull請求發送回發布分支。 但是當bug修復發布分支時，似乎沒有明顯的git-flow進程來處理發布分支的分支。

什么是用於修復發布分支錯誤和代碼審查的git-flow流程？

您是否應該修復開發中的錯誤並創建新的發布分支？ 分支發布分支仍然是有效的git-flow？ 在發布分支錯誤修復上處理拉取請求代碼審查的最佳方法是什么？

Answer 1

我剛剛遇到同樣的問題。 我建議從發布分支創建一個普通的分支。 在那里進行修復並為該分支創建一個pull請求以合並到release分支。 這是使用普通的分支和合並命令，而不是Git Flow命令。

步驟詳情如下：

1. 結帳發布/ 2017.05.24分支。 2017.05.24是發布分支的名稱。
2. 執行branch命令並將其命名為“release2017.05.24 - 修復原因”。 這將顯示分支存在的原因（對於發布修復）。
3. 進行更改，提交，將更改推送到服務器（將分支推送到源）。
4. 在您的服務器中，為您的分支創建一個pull請求以合並到release / 2017.05.24分支。 注意：合並到發布/ 2017.05.24分支不是默認值，因此請務必在創建拉取請求之前更改它。
5. 在代碼審查批准結帳“發布/ 2017.05.24”
6. 在“release2017.05.24 -reason for fix”分支中執行合並命令選擇提交。
7. 刪除“release2017.05.24 - 修復原因”分支的本地和遠程分支

希望這會更好。 Git-flow命令集中有很多步驟和制動，但應該允許拉取請求發生。

Answer 2

我處理它的方式是在發布分支上有一個修補程序分支。 修復錯誤后，我將合並到master / release分支，並合並到Dev分支，然后逐漸滲透到其他功能。

然后將刪除此修補程序，因為它將記錄在master或dev 。

Answer 3

錯誤修復分支應該分支主（或任何分支代表您的生產代碼）。 如果您正在使用git flow，這有時意味着如果您已經在開發分支中進行了代碼更改，那么您必須選擇提交到錯誤修復分支。