在 gitflow 中處理發布分支

Question

我工作的公司正在使用 gitflow。

我們遵循每個功能分支的方法，其中實現、測試各個功能，然后 PR'd 到開發中。 當需要發布時，我們會在開發之外創建一個發布分支——我們會在發布分支上觸發構建並將其部署到測試環境中。 由於合並到開發中的多個功能分支，可能存在一些集成缺陷。 這些直接針對發布分支解決。 一旦我們對發布分支的 state 感到滿意，我們就會將其部署（與 QA 簽署的完全相同的構建）到 PROD。

在這個階段，我們需要讓我們的發布分支代碼回到 develop 和 master，這兩個都是受保護的分支。 假設有一些針對發布分支的提交，我們需要做 2 個 PR，即一個用於 release->develop，一個用於 release->master。

幾個問題：

1. 人們如何審查直接針對發布分支的提交？ 我們可以在實際發布之前通過 PR 進行開發，但這對我來說似乎有點不合時宜。
2. 人們如何將發布分支合並到 develop AND master 中。 develop 的 PR 只是直接針對發布分支進行的提交，而 master 的 PR 還將包括已經 PRd 到 develop 中的所有功能。 PR to master 似乎有點過時了。

謝謝。

Answer 1

tl;dr：理想情況下，執行例行 Git Flow 分支合並時不需要代碼審查。 相反，您將確保對 Git Flow 共享分支的所有提交都經過代碼審查。 請注意，此解決方案回答了您的兩個問題。

詳細信息：在您的示例中，將release合並到master或將release合並到develop （理想情況下）不需要人工干預，理論上可以自動化¹ 。 不過，為了實現這一點，您確實需要對 go 到release的所有提交進行代碼審查，這意味着您需要調整工作流程的這一部分：

由於合並到開發中的多個功能分支，可能存在一些集成缺陷。 這些直接針對發布分支解決。

如果您從release創建功能分支並通過正常的代碼審查將它們 PR 到release分支，那么稍后當需要將release合並到另一個共享 Git Flow 分支時，您可以放心， release分支上的所有代碼都已經是代碼經過審查，合並成為常規合並，不需要進行深入審查。

許多 Git SCM 工具都有受保護分支的概念，需要使用 PR 才能將代碼合並到其中。 這里的建議是除了保護develop和master之外，你還應該保護你的release和hotfix分支。

提示：在完成release分支時， Git Flow 建議將release分支合並到master和develop中。 然而，有一種稍微更有效的機制可以實現相同的state ，但有一些額外的優勢。 調整是先將release合並到master ，然后再將master合並到develop 。 這樣做的好處是master上的新合並提交也將在develop上，這意味着develop比master “領先”。 當需要將下一個release分支合並到master時，從提交 ID 的角度來看，它將完全是最新的，這意味着您可以進行快進合並。 當然，您仍然會像 Git Flow 推薦的那樣使用--no-ff合並到master中，但是知道您可以快進可以肯定地告訴您合並后master的 state 與您測試的release分支相同。 如果您不這樣做，則必須比較狀態以確保您不會破壞您忘記合並回release或develop的master上的修補程序。 另一個小好處是，如果不這樣做，如果您連續發布了多個版本，那么第一次進行hotfix時，您將第一次將一堆舊的合並提交從master合並到develop中，這有點令人困惑看到那個。

---

¹ Git 流共享分支合並通常可以自動完成。 只有在存在非確定性合並沖突的情況下，人才需要介入。 不確定性沖突的一個例子可能是將release或master向下合並到develop時，在創建release分支后，兩個分支中的某些文件都發生了變化。 請注意，某些沖突可能被認為是確定性的，並且仍然可以通過邏輯自動解決，例如在兩個分支中修改的版本文件，並且解決機制是事先已知的。