Question

我们正在从cvs转向tfs，基本上是在tfs中导入最新版本并在cvs中支持旧版本。我已经阅读了75页的TFS版本控制分支策略，它似乎将使用＆＃34;开发和发布隔离＆＃34;策略......但似乎无法在源代码管理中描绘目录树。我的老板说我们应该永远不应该开发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_V10U02分支，因为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 DEV分支合并到MAIN，然后从MAIN创建1个REL分支，反映实际发布的代码。

简而言之，每次实际发布到生产中都应该有1个REL分支。

TFS分支合并结构多个版本

1 个答案: