使用TFS分支管理发行版/特性

Question

因此，几天来，我一直在绞尽脑汁，试图想出一种有效的方法来管理TFS分支的发布/迭代。

情况如下：

我们有一个我们有版本的项目，对于每个版本我们都有迭代。发行版是我们投入到生产中的新版本，迭代只是需要在QA中测试的开发阶段。

迭代有点像特性。假设您想要开发一个网站来显示项目(迭代1)，然后出售它们(迭代2)并将其打包到第一个版本中。对于QA修复，它是在迭代分支中完成并合并到QA中的。因为我们没有在QA中提交，所以当我们合并时没有冲突需要解决。

因此，工作流看起来是这样的(由于时间紧迫，许多并行的工作需要完成)：

• 对于第1版
  1. 启动迭代1的开发
  2. 启动迭代2的开发
  3. 迭代1进入QA
  4. 启动迭代3的开发
  5. 迭代1 QA完成
  6. 迭代2进入QA

​

• 第2版开始..。

在简历中，大量并行开发，一次在QA中进行一次迭代，当所有版本的迭代都经过QA时，它就会进入生产阶段。

因此，我们需要想出一个分支解决方案，允许在开发分支之间轻松地合并，然后进入QA分支。到目前为止，我们提出了这个分支结构

- Main
   |- QA_Release_1
   |  |- DEV_Iteration_1
   |     |- DEV_Iteration_2
   |        |- DEV_Iteration_3
   |- QA_Release_2
      |- ...

这样，我们就可以很容易地在dev分支之间合并。但是在迭代1 QA结束时，我们禁用分支(要么删除它，要么拒绝访问以签出/进入)。当这一时刻到来时，策略是将DEV_Iteration_2重新父代为QA_Release_1。

要做到这一点，我们需要进行无根据的合并，这将创建一个冲突的。如果我正确理解，一个没有根据的合并只是一个文件夹比较，而没有考虑到以前发生的更改集合并。

因此，我想第一个问题是，我们这样做会给自己带来多少合并麻烦(如果有的话)？仅仅忽略巨大的合并，在修复过程中修复大量的冲突，这样做可以吗？

第二个问题是:是否有更有效的方法来实现这一目标？

编辑:我想念吉特.

我们继续寻找解决方案，一位同事给我发了这个链接：

Gitflow工作流

也就是说，如果你拿出与git直接相关的东西，我们需要做的正是。在TFS中可能是这样的：

- Main
   |- Develop
      |- QA_Release_1
      |- DEV_Iteration_1
      |- DEV_Iteration_2
      |- QA_Release_2

问题是，TFS不喜欢跳过分支。一旦你没有在父或子中合并，它就被认为是毫无根据的合并。因此，由于QA_Release_1是在Develop下创建的，所以很难合并到Main中。这使我回到我的第一个问题:无根据的合并是一个陷阱吗？

Answer 1

在我的工作中，我使用以下模型：

分支机构：

1. 主干/主分支
   • 构建和自动化测试是可以的
   • 没有未完成的工作(如果更改需要多次提交，请使用特性分支)
   • 准备好成为发布候选版本(如果更改引入了任何阻止程序，则不在此提交)

​

1. 特征分支

- created if a feature or a fix needs more than one commit
- a branch for a specific feature or a bug fix
- everything is allowed: broken build, failing tests
- eventually is merged to trunk
- occasionally trunk is merged to it (to reduce deviation between branches)
- before merge to the trunk everything should be cleaned

​

1. 稳定支路
   • 为支持的每个版本创建
   • 匹配某些主干的修订版+一些更改的合并(稍后+解决方案)
   • 用于手动测试的构建是从这里创建的。

​

工作流：

1. 小功能/修复：
   • 只管去干

​

1. 大特性/修复：
   • 创建特征分支
   • 在那里作出许多承诺
   • 合并到中继线
   • 删除功能分支

​

1. 修复手动测试发现的错误：
   • 修复后备箱(由#1或#2)
   • 合并到稳定处

​

1. 解决方法(快速和肮脏的修复，稍后我们将清理)：
   • 直接固定在稳定支路上
   • 不要合并到主干

​

我在SVN和TFS上使用了它，它似乎不会造成问题。由于所有分支都是从主干创建的，TFS在合并方面应该没有问题。