版本控制（TFS）的兩種方法：需要建議

Question

我們已經在我們的項目中達到了一個需要進行生產部署但還需要持續開發未來功能的點。我們的源代碼管理目前有一個開發分支。在我以前的公司中，開發，集成，生產部門設立了3個分公司系統。功能開發是在開發中完成的，在集成和生產中進行測試始終是在當前生產環境中運行的代碼（除了從Integaration到Production以及完成部署完成合並的時間之外）。

每當進行生產更改或合併到現場部署的生產中時，新的歸檔分支將被移出生產並給出版本號。對較高分支的任何更改都會合並回來，因此Production中的更改將使其回到開發階段。它的工作，但我一直沒有看到需要一個持續的集成和生產分支。

我真的不喜歡這個系統的兩個方面：1）從集成分支合併到生產分支：我希望每次都有一個「乾淨的」生產分支，即使它們在合併後應該同步2）該系統不允許同時運行不同版本的代碼的系統的多個部署，儘管這對於我曾經工作過的團隊來說並不是必需的。

我聽說過這個模型很常見，但在系統中，我建立我現在提出了以下幾點：

有一個發展分支，創建一個新的發佈分支每次發展爲準備下一個部署生產。版本分支被賦予版本號，然後再次分支到歸檔分支。測試在Release分支上完成。部署完成後，在發佈分支中完成任何生產修復，然後在部署獲得批准後，創建新的歸檔分支，並添加次要版本號增量。當開發的新部署準備就緒時，將創建一個新的發佈分支...

對我來說，這更簡單，實際上更好：沒有Integaration分支（較少合併），並且有一個新的Production（發佈）爲每個部署分支並迎合當前生產版本。我錯過了什麼？爲什麼選擇開發，集成，生產模式？

感謝

Answer 1

3分支系統的優勢在於您的開發人員，測試人員和客戶各自擁有自己的獨立版本/代碼分支。這提供了一個「門控」開發，其功能只有在它們通過某個完整性/質量條時才能提升到下一個分支，從而高度確信發佈分支始終處於適合發送給客戶的狀態。

優點：

• 你（幾乎）總是有可能在瞬間被髮送到客戶注意到一個版本。
• 您的測試人員（幾乎）總是有一個工作版本來測試
• 發佈分支是穩定的，因此您通常不必修復其中的錯誤並將它們反向合併到測試/開發分支中。

缺點：

• 你必須經常合併推動完成功能到發佈分支。這並不算太壞，因爲這種合併只是一種快速複製操作（只要您不在測試/發佈分支​​中進行編輯，您就不會遇到合併衝突）

如果你只需要一個單獨的開發分支的方法，當你需要一個版本時，你就可以從中分離出一個分支，那麼你大部分時間都在非分支系統中有效地工作。也就是說，您的開發分支中有一個不穩定的正在進行的構建，然後將其複製到發佈分支中，在那裏將其作爲正在進行中的工作，直到它穩定下來以釋放質量。如果您在修復發行版分支時繼續在開發分支中開發功能，那麼您將收到大量合併衝突來解決。如果沒有一個好的構建來測試，你會花費很多時間，如果沒有可釋放的構建，你可以根據需要發佈。

當您發佈時，並不需要將代碼分支到歸檔分支中 - 您只需在執行發佈時標記代碼以獲得可靠的「快照」即可將來恢復。

Answer 2

你的建議聽起來跟我的工作方式：

• 我主分支發展，直到我的發展準備
• 然後創建一個發佈分支，比方說1.5版
• 發佈分支經過測試後，再次分支，調用它1.5.1
• 修復Bug在主分支和所有活動的版本b牧場（例如釋放分支機構的1.3，1.4，1.5）
• 定期的新版本（分公司）創建和發送給客戶（如1.5.2，1.5.3，...）

在我的經驗，這作品相當不錯，但可能還取決於貴公司的組織方式。

Answer 3

您的建議不會太偏離建議。 該模型的主要區別在於，您建議您直接在之前的「集成」分支上進行開發。很多人建議從這個分支開始分行開展工作，然後重新合併。但這取決於你的團隊的規模。

與TFS分支工作的極其寶貴的資源是在這裏：我曾經工作

http://tfsbranchingguideiii.codeplex.com/

Answer 4

一個地方有一個分支每個版本。我們花了更多時間進行分支，而不是合併。這有點過分。

如果您想到具有連接節點圖形的心智模型，生產分支只是連接到主集成分支的另一個節點。