分支和合並策略

Question

我的任務是在未來6個月內提出分支，合併和釋放策略。

併發症來自於我們將運行多個項目，所有項目都有不同的代碼更改和不同的發佈日期，但大致相同的開發日期。

目前我們正在使用VSS進行代碼管理，但意識到它可能會導致一些問題，並將在新開發開始之前遷移到TFS。

我應該採用什麼策略，在制定計劃之前應該考慮哪些事項？

對不起，如果這是模糊的，隨意提問，我會根據需要更新更多的信息。

Answer 1

這是我遇到的最好的source control pattern。它強調了讓箱子免於任何垃圾（箱子裏沒有垃圾）的重要性。開發應該在開發分支中完成，定期合併（在代碼測試之後）應該重新進入主幹（圖1），但該模型還允許在開發過程中修補源代碼（圖2）。我絕對推薦閱讀整篇文章，以便完全理解。

  Pic 1

  Pic 2

編輯：這些照片是絕對沒有的話混亂。我可以解釋，但我基本上是抄襲原作者。話雖如此，我可能應該選擇一個更好的圖片來描述合併過程，所以希望這有助於。然而，我仍然建議閱讀這篇文章：

Answer 2

顛覆書描述some common branching patterns。也許你也可以將這些應用到TFS。

Answer 3

我的第一個建議是閱讀Eric Sink的Source Control HOWTO - 特別是branches和branch merge章節。

我們有3個容器 - DEV，MAIN和RELEASE用於我們的工作。 MAIN包含我們所有的「準備發佈」代碼，我們傾向於認爲它「基本穩定」。 DEV/Iteration（或DEV/Feature或DEV/RiskyFeatureThatMreakBreakSomeoneElse）是從MAIN分支的，並且在Iteration/Feature準備好向上推進DEV環境時合併。我們還有從DEV/Iteration分支和MAIN分支設置的TFS構建。

我們的RELEASE容器包含編號版本（類似於許多Subversion版本庫中使用的「tags」容器）。我們每次只需從MAIN處獲得一個分支 - 我想說我們正在「切割」一個RELEASE分支，以表示這個合併完成後應該不會有很多活動正在進行。

至於與VSS> TFS - 微軟支持的upgrade path這應該保持你的版本歷史記錄，但如果你不需要它的歷史，我只想得到VSS的最新版本，檢入和TFS存檔VSS存儲庫。

最後一個提示 - 讓您的團隊成員熟悉源代碼管理。 他們必須理解分支和合並或者你會被困住做很多清理工作:)。

祝你好運！

Answer 4

我看到分支工作最簡單和最常見的方式是關閉兩個前提。中繼和釋放。我認爲這被稱爲「不穩定的樹幹，穩定的分支」哲學。

中繼線是您的主要來源。這包含「最新和最偉大」的代碼，並且具有前瞻性。它通常並不總是穩定的。

版本號是一個與trunk的一對多關聯。有一個主幹，但有很多從主幹派生出來的版本。一旦一個特定的功能里程碑被擊中，發行版通常從一個分支的樹幹開始，所以留給特定部署留下的「唯一」東西應該只是bug修復。然後，您將樹幹分支，給它一個標籤（例如1.6 Release是我們當前的最新版本），構建併發送到QA。此時我們還會推送中繼的版本號（通常是次要號碼），以確保我們沒有兩個具有相同號碼的版本。

然後你開始你的發佈分支的測試周期。在進行了足夠的測試後，您會將錯誤修復應用到發佈分支，並將它們合併回主幹（以確保錯誤修復已結轉！），然後重新發布分支的構建版本。這個包含質量保證的週期會持續下去，直到您高興並且最終發佈給客戶。來自客戶的任何錯誤報告都是準確的（即它們是一個錯誤！）將啓動與該分支有關的另一個QA週期。

在您創建未來版本時，同時嘗試將舊客戶遷移到較新的分支機構以減少潛在的分支機構數量，這些分支機構可能需要將補丁程序修補到補丁程序中。

使用此技術，您可以使用您的技術將解決方案部署到需要不同服務級別（從最低開始）的各種客戶，您可以將現有部署與主幹中「危險」的新代碼隔離開合併方案是一個分支。