TFS分支合并结构多个版本

Question

我们正在从cvs转向tfs，基本上导入tfs中的最新版本，并支持cvs中的旧版本。我已经阅读了75页的TFS版本控制分支策略，它似乎会使用"开发和发布隔离"策略。。。但似乎无法描绘源代码管理中的目录树。我的老板说我们不应该开发n MAIN。

我得到了MAIN、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_V10UO2分支，因为QA没有得到U02的构建。

在我看来，这个计划似乎不对。我们可以对一个版本进行多达20-30次更新，不仅如此，当我们开始下一个主要版本时，它会从头开始，所以我认为文件夹肯定应该被利用。在中使用dev、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分支，这个版本的所有错误修复都会在这个分支上完成，然后在更新发布到客户端时合并回main，从main到dev。

我是不是遗漏了什么？

Answer 1

对于典型的分支模式，所有（大多数）开发都应该在DEV分支中完成。REL分支仅用于存储已发布代码的快照。您通常不应该在Release分支中进行开发。

当你说更新时，我想你的意思和功能是一样的。因此，V10版本可能有10个独立的功能。听起来你正在尝试建立一个按功能分支的模型（这会导致更多的合并，但会提供更多的开发隔离和发布灵活性），如果是这样的话，你通常会有10个DEV分支（每个功能/更新一个），它们10个DEW分支会合并到MAIN中，则从MAIN创建1个REL分支，该分支反映所发布的实际代码。

简而言之，对于每个实际的生产发布，您应该有一个REL分支。