GitFlow：正確測試發行分支和碩士

Question

我一直在git中尋找一個好的分支模型，發現GitFlow非常適合我們的開發環境。 但是，一個懸而未決的問題是如何以及在何處測試我們的版本。

發布分支聽起來像是在發布之前運行所有回歸測試的地方。 然而，發布分支然后合並到master，tagged，這就是最終生產的東西。 如果從發布分支到主服務器之間存在合並沖突，會發生什么？ 聽起來像主人需要完全重新測試（這可能是昂貴的）。 即使沒有沖突，簡單地將合並推送到生產中是否安全，或者是否需要運行額外的基本煙霧測試？

Answer 1

仔細追查后GitFlow圖，我相信自己，融入主站時永遠不應該有任何沖突（也就是當這個過程嚴格遵循）。 原因是因為時間表：

1. 開發分支是由Master創建的
2. 功能在Develop分支上提交
3. 創建發布分支（包括目前為止所有來自Develop的提交）
4. 錯誤在Release分支中修復
5. 准備好后，Release分支將合並到Master中
6. Master必須包含Develop + Release分支的所有提交。 沖突不應該發生，因為在創建開發分支之后沒有對Master進行任何操作（這是沖突發生的唯一方式）。 此外，此時的代碼應與Release分支上的最新提交相同，這意味着無需進行其他測試。

我簡化了GitFlow圖來說服自己：

Answer 2

我認為應該在發布的每個階段進行測試。 創建一個輕量級的發布測試，您可以直接針對生產運行，以至少測試基本功能。 當然，不要對生產進行加載/性能測試。

根據您的產品以及如何推出產品，實際測試可能會發生變化。 我們有一些生產服務器，我們部署了新的發布代碼。 這些服務器經過徹底測試，但我們的客戶無法訪問。 當這些簽出時，我們將其與其他生產服務器交換出來。 重復部署和測試。 一切都過后，所有生產服務器都會重新投入到面向客戶的服務器的實時池中。

如果發生某些故障，我們會以同樣的方式回滾。