團隊基礎服務器開發結構

Question

我是一個正在從Visual Source Safe轉移到TFS2010的小型開發團隊的一員。

我一直在閱讀有關TFS結構和橫跨在上面的鏈接，我不知道關於提到very good question.

一兩件事來是發展結構：

- Development/ 
     - Trunk/ 
      - Source/ 
      - etc/ 
     - Branches/ 
      - Source/ 
      - etc/ 

我不您真的不需要將Trunk和Branches作爲單獨的兒童容器加入Development。我如何讀取此結構是Trunk將從Integration（或Main，如果您使用MS術語）分支並且Branches然後將從Trunk分支（即Trunk是多個Branches的父親）。

如果是這種情況，我不明白層次結構中額外層的優點。什麼似乎是合乎邏輯，我（記住，我一直在學習這個東西了大約一天）是，如果你想多開發分支，讓每個開發分支爲Development容器的子：

- Development/ 
     - DevBranchOne/ 
      - Source/ 
      - etc/ 
     - DevBranchTwo/ 
      - Source/ 
      - etc/ 

在上述結構（其中DevBranchOne和DevBranchTwo被替換爲有意義的名稱），開發分支是兄弟並且從Integration（或Main）分支。鑑於上述情況，我的問題是：

1. 是我在Development正確的預期用途Trunk的理解？
2. 如果我的第一個問題的答案是肯定的，那麼在Development中實現這樣的層次結構有什麼好處？
3. 使用Trunk簡單的東西是從SVN（我沒有經驗）結轉？

Answer 1

我同意，在你鏈接到的帖子中，他有2個「中繼線」，開發\中繼線和集成，這只是他在上下文中出現的另一個名稱。

根據您的分支策略，您通常只需要一個「主幹」（或集成分支）。

但是，在某些情況下，您可能需要多個集成分支，例如，如果您正在按分支功能進行分類，但還需要將各個功能分支需要集成到一起的特徵組概念在集成到子系統的集成分支之前，該功能組將被集成到產品主集成分支（aka trunk）中。

但是，大多數分支策略只需要一個集成分支。

Answer 2

我不一定建議使用this other question作爲模型。這聽起來像是他們將多個功能分支集中到一個集成分支（「Trunk」）中，然後再集成到另一個集成分支（「集成」）中。這看起來像是一個適合他們現有工作流程的分支系統 - 雖然這個系統肯定沒有問題，但它不適合我的工作流程，你必須改變你的工作流程。

換句話說，你可能已經知道你是否想要一個像這個問題中描述的分支系統。你對你所期望的內容的描述可能是一個很好的起點：多個開發分支和一個主幹（或者主要的，或者你想稱之爲的任何分支）的分支。

如果您還沒有，請務必查看來自Visual Studio ALM Rangers的TFS branching best practices。