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分支合并结构多个版本

回答

相关问题