TFS分支合併結構多個版本

我們正在從CVS轉向tfs，基本上在tfs中導入最新版本，並在cvs中支持舊版本。我已閱讀了75頁TFS版本控制分支策略，似乎將使用「開發和釋放隔離」策略......但似乎無法在源代碼管理中描繪目錄樹。我的老闆說我們應該永遠不應該開發n MAIN。TFS分支合併結構多個版本

我讓主，DEV和REL分支機構，但我們的發佈工程誰說，這是老闆要求與對了ProductX版本的10家分公司開始：DEV_V10U01，MAIN和REL_V10U01幾個產品，如：

CollectionName 
    ProjectA 
     DEV_V10U01 
     DEV_V10U02 
     MAIN 
     REL_V10U00 
     REL_V10U01 
     REL_V10U02 
    ProjectB 
     ...

REL_V10U01已經發布給客戶，我猜目前的開發正在進行DEV_V10U02，不知道爲什麼有一個REL_V10U02分支，因爲QA還沒有構建U02。

對我來說這個計劃似乎不對。我們最多可以對發佈進行20-30次更新，不僅如此 - 當我們開始下一個主要發佈時，它會從頭開始，所以我相信文件夾肯定會被利用。難道是有意義的使用像開發，V10和rel文件夾中：

Collection: 
    ProductA 
     dev 
      v10 
       DEV_V10U01 
       DEV_V10U02 
     MAIN 
     rel 
      v10 
       REL_V10U01 
       REL_V10U02

還是應該像：

Collection: 
    ProductA 
     v10 
      dev 
       DEV_V10U01 
       DEV_V10U02 
      MAIN 
      rel 
       REL_V10U01 
       REL_V10U02 

     v11 
      dev 
       DEV_V11U01 
      MAIN 
      rel 
       REL_V11U01

我很困惑，爲什麼我們的DEV和REL同名？對於我來說，我認爲我們會創建下一個rel分支，這個版本的所有bug修復都會在這個分支上完成，然後當這個更新被髮布到客戶端時，合併回main，並且從main到dev。

我在這裏錯過了什麼嗎？

來源

2014-10-16 Tom

對於典型的分支模式，所有（大部分）開發都應該在DEV分支中完成。 REL分支僅用於存儲已發佈代碼的快照。您通常不應該在Release分支中進行開發。

當你說更新時，我會假設你的意思與功能相同。所以V10版本可能有10個獨立的功能，它們是其中的一部分。這聽起來像你正在試圖做一個分支按特徵模型（這會導致更多的合併，但提供更多的開發隔離和發佈靈活性），如果這樣你通常會有10個DEV分支（每個特徵/更新一個），他們10 DEV分支合併到MAIN中，然後從MAIN創建1個REL分支，該分支反映了實際發佈的代碼。

總之，每個實際發佈到生產中應該有1個REL分支。

來源

2014-10-17 19:49:10

並且不要忘記研究流浪者的指導https://vsarbranchingguide.codeplex.com/。有很多爲什麼以及何時應用某種模式。 – 2014-10-18 09:56:41

雖然很多人不同意巡警指導，因爲過於複雜並且往往是不正確的。這是一個好的開始，但我更經常推薦通過發佈分支而不是主線分支。 – 2014-10-20 06:18:09

謝謝迪倫，當我說更新 - 我的意思是主要版本的補丁。我們每年發佈一次主要版本。客戶可以在系統上安裝多個版本 - 一旦他們比較結果並且他們不會卸載以前的版本。 – Tom 2014-10-21 12:43:25

TFS分支合併結構多個版本

回答

相關問題