GitFlow：先合並到 master 還是在產品發布后合並？

Question

在學習 GitFlow 時，我有一些擔憂，但在我讀過的任何文檔/文章中都沒有看到這些擔憂。

在某些時候， develop分支上的代碼需要部署到 QA/staging 環境並進行嚴格測試。 因此，使用 GitFlow，您可以從develop中切出一個release分支，然后將release部署到所述暫存環境。

首先，只是想快速澄清一些事情：特定項目/回購第一次經歷這個過程，你實際上是從develop分叉/創建這個新的release分支，是嗎？ 並且在未來的所有其他時間，您只是將develop合並到release中，是嗎？

然后 QA 在暫存環境中測試release分支，一切看起來都很好，我們准備好部署到 prod。 你：

• 部署到 prod，然后將release合並到master中？ ; 或者
• 合並release到master ，然后部署到 prod？

我問是因為在前一種情況下，您似乎需要將release分支部署到 prod，然后部署到 prod，然后合並到master 。 這聽起來不錯，但通常生產環境和非生產環境並不相同，並且在暫存中運行得很好的代碼在生產服務器上第二次啟動時會發生阻塞。 我知道 GitFlow 支持熱修復分支的概念，但它們是為小修復保留的。 在需要回滾/退出版本的復雜修復的情況下，我們現在將“臟代碼”（由於某種原因破壞產品的代碼）合並到master中。

在后一種情況下，從合並並放入產品發布請求到產品部署實際發生可能需要數小時甚至數天（尤其是如果您需要讓 IT/Ops 參與產品部署） . 在此期間，您有一個master分支，上面寫着“功能 X、Y 和 Z 正在生產中”，但實際上並沒有。

我想知道 GitFlow 是否真的以某種方式解決了這個問題，或者這兩種情況的已知解決方法是什么。

Answer 1

我工作的項目非常混亂，決策在幾分鍾內就會發生變化，所以我的策略是盡可能拖延軟件配置管理決策。

特別是合並到 master：我們只有在部署到生產環境后才合並到 master，並且我們有一封確認電子郵件，表明冒煙測試工作正常。 這樣，我們通過管理決策變更、部署回滾、技術問題或任何可能發生的問題的風險來應對混亂。

一開始我們在進入生產之前合並到master，但是最后一分鍾的技術問題，回滾，管理決策......給我們帶來了很多問題，所以我們改變了策略，並且在過去的3年中一直運作良好年。

如果最終在投入生產后發現一些回歸，那就是一個修補程序，必須像這樣處理:)

Answer 2

您創建的發布分支是一個短暫的分支，類似於您創建的功能分支。 發布完成后，刪除分支。 例如，我會創建一個release/0.1.0分支，完成工作，然后合並。

部署到生產時，我總是從 master 分支中獲取代碼，這意味着我在部署之前先將 release 分支合並到 master 中。

GitFlow 更多的是關於前進，而不是后退。 因此，為什么要使用修補程序來為已識別的問題創建修復程序。

就進入生產所需的時間而言，這真的不是 GitFlow 關心的問題，我認為它不會在這方面提供太多幫助。 無論您使用哪種分支策略，這對您來說都是一個問題。

Answer 3

你實際上會從開發分叉/創建這個新的發布分支，是嗎？

那是正確的。 第一次你唯一的選擇是從你的主分支創建release分支，這就是你將部署的 QA/Staging，然后部署到生產。

並且在未來的所有其他時間，您只是將開發合並到發布，是嗎？

這取決於。 根據 Git Flow 的描述，release 分支是一個短暫的分支。 它可能只從develop分支出來，並合並到master 。 理論上， release應該在你的 release 完成后合並回develop ，然后被刪除。 您應該合並到發布中的唯一內容是hotfix 。 這是一篇關於流程的好文章。

這因一支球隊而異。 我曾在完全遵循 GitFlow 描述的團隊中工作，而其他人則選擇只刪除release並從開發中重新創建它，就好像這是第一次一樣。

部署到 prod，然后將 release 合並到 master 中？； 或合並發布到主然后部署到生產？

從理論上講，master 應該始終包含生產就緒代碼，而確保這一點的唯一方法是部署到生產的內容正是master 分支中的內容。 也就是說，我們可能無法為您提供特別適合您團隊的完美答案。

例如，我目前在一個擁有 CI/CD 管道的團隊工作，這讓我們別無選擇，只能先合並：部署從master自動發生。 我見過一些團隊發布的版本相距太遠，我更有信心部署release分支，然后再合並。 這避免了部署在release期間出現的人為錯誤 -> master合並（這可能包括隨着時間的推移而產生的令人討厭的沖突）。

我相信您應該選擇最適合您的解決方案，因為 GitFlow 可能無法涵蓋所有​​可能的場景和上下文。

Answer 4

從 master 部署適用於小商店。 在必須支持多個版本的情況下，您應該從發布分支進行維護和部署。

Answer 5

在我以前的團隊中，分支策略是創建一個發布分支並對發布分支進行最終測試，並在部署之前將發布分支合並到主分支。然后使用主分支進行生產部署。

但我目前的團隊使用的是一種不同的方法，即在成功部署產品后，將發布分支部署到生產環境，並將發布分支合並到主分支。 這種方法的好處是確保代碼在真實的生產環境中工作，所以我們可以說代碼已經在生產中正確運行，然后將發布分支合並到 master，所以 master 中的一切都在現實中工作。 這種方法的另一個優點是，如果部署出現問題，只需使用主分支重新部署即可輕松回滾。

對於以前的方法，我有回滾更改的經驗，因為生產環境更復雜，並且在部署之前在非生產環境中沒有發現問題，所以我需要 rebase/revert master 分支中的更改，這意味着 master 分支是在我做 rebase/revert 之前已經壞了:(

我喜歡在發布分支上發布並在產品部署后將其合並回母版的東西很容易回滾，並通過在實際生產環境中運行代碼來確保母版中的代碼正確，而不僅僅是在非產品環境中。

最后，它仍然取決於哪種方法適合您的項目/團隊。

Answer 6

我認為您首先部署然后合並的原因是因為在您的 CI/CD 管道中，您可以在部署后進行一些冒煙測試，如果事情不穩定，您可以通過部署最初在 master 分支中的內容來進行還原，由於您的管道失敗，因此不會發生與 master 的合並。

但是，如果你先合並然后部署，那么恢復可能會很棘手，因為你必須恢復合並......所以我認為從發布部署是有意義的，如果事情穩定，那么你合並到 master。