Git 分支策略 - 合並時丟失更改

Question

我們有一個包含開發、發布和主分支的分支策略。 功能/錯誤從發布中分支出來。 完成后，它們合並到開發中以進行 QA 測試。 一旦 QA 通過，它們（直接從功能/錯誤分支）合並到發布中以進行發布回歸測試。 在最終回歸測試后發布合並到主控。 修補程序從 master 分支，合並回 master。

盡管如此，在合並分支時，我們有時會丟失發布和 QA 的更改。開發人員在合並到 QA 和發布之前從發布合並到他們的分支，但從不從 QA 合並。

此策略是否存在任何概念問題？ 我們可能會丟失這些更改的任何潛在原因？

Answer 1

您的策略是合理的，並且有一個名稱： gitworkflow ，它允許僅合並您在QA或release中想要/需要的功能分支（而不是合並從 QA 到發布的所有內容）

但這並不能解釋任何“丟失的更改”：這將是由合並沖突解決引起的，它以某種方式保留一個更改並覆蓋另一個並發更改。

開發人員正在從發布合並到他們的分支

這是我能看到的唯一缺陷。 沒有從release或master進行合並。 這些是您合並to的分支，而不是from .

最佳實踐是在預期的合並目標（ QA或release ）之上重新構建一個dev分支，然后合並它們。

Answer 2

我們有一個包含開發、發布和主分支的分支策略。

這聽起來有點像Gitflow 。 但是您描述的 rest 沒有。 因此，我假設您是故意使用其他東西，而不僅僅是誤解了 Gitflow。 那絕對沒問題，但是由於某些原因，IMO 您的概念存在缺陷。 我這么說是因為你直接問：

此策略是否存在任何概念問題？

所以是的，有。

功能/錯誤從發布中分支出來。 完成后，它們合並到開發中以進行 QA 測試。

這聽起來有點奇怪。 功能應該從開發分支出來，QA 直接在他們自己的分支中測試，只有在 QA 通過后才合並回開發，隨后您可以在其中進行額外的集成測試。

附帶說明：在我擔任教練的項目中，我們通常有一條規則，即從下屬（不太穩定）到更高級別（更穩定）的分支總是必須快進。 即，如果在功能開發過程中，某些其他功能碰巧已經過 QA 測試並比當前測試的功能更早地合並回開發中，則必須從開發中刷新功能分支，盡可能多地重新測試，然后才快速轉發回到發展。 這意味着，功能 QA 測試和集成測試都在功能分支中完成。 一個功能或錯誤修復只有在明確它不僅可以單獨工作而且還可以與之前已經被接受到開發中的所有其他工作集成之后才被合並回開發中。 我稱之為“沒有意外”規則。 情況“哦，在功能分支上它正在工作，為什么它在開發分支上不起作用？” 根本不可能發生，甚至不需要額外的合並后集成測試，因為這是一個快進。

因此，這與 VonC 在他的回答中所說的直接相矛盾：

從發布版或主版中不會進行任何合並。 這些是您合並的分支，而不是來自。

我不能再不同意了。 應該定期從較高級別的分支刷新下級分支，因為根據較高級別的定義，總是有工作被接受合並（或快進）之前，即您不可避免地必須與它們集成. 合並沖突或合並后集成問題應該在功能或錯誤修復分支中修復，然后再接受並將它們合並回更高級別的分支。 IMO 絕對不能用新引入的不穩定性來搞亂一個更高級別的分支，然后清理那里的混亂。

一旦 QA 通過，它們（直接從功能/錯誤分支）合並到發布中以進行發布回歸測試。

之前，您說過您在開發中進行集成測試，即您在那里解決合並沖突，這可能與您在將功能合並回發布時遇到的（如果有的話）完全不同。 此外，您正在合並經過集成測試以外的其他內容。 因此，即使沒有沖突並且一切都非常順利，您正在合並的內容和您一直在測試的內容是不一樣的。 這是非常危險的IMO。 在您的設置中，發布分支包含除開發之外的其他內容，並且您似乎濫用了-對於自以為是的術語感到抱歉，但我確實持有這種觀點-開發為某種解決沖突和集成測試的沙箱，只是不合並稍后從那里返回發布分支。

您沒有像 Gitflow 或簡單的功能分支工作流程那樣的清晰的分支層次結構。 我認為這很危險，而且會帶來麻煩。

在最終回歸測試后發布合並到主控。

看？ 這是另一個副作用：您對功能進行 QA 測試，然后進行集成測試開發，合並其他內容，然后必須再次重新測試（“最終回歸測試”），這對於良好的分層分支來說甚至是不必要的和合並策略。

修補程序從 master 分支，合並回 master。

我想說更多，但在這種情況下，它不是問題的根源，因為至少這是分層的。 你合並回到你分支的地方。 只要您定期從 master 刷新從屬分支，以便在那里也有修補程序，好的，但只有這樣。