使用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。

要做到这一点，我们需要进行毫无根据的合并，这会产生很多的冲突。如果我理解正确，无基础合并只是一个文件夹比较，而不考虑之前发生的变更集合。

所以我想第一个问题是我们通过这样做会有多少合并问题（如果有的话）？是否可以忽略巨大的合并并在重新定位时修复大量的冲突？

其次是：有没有更有效的方法来实现这一目标？

编辑：我想念git ......

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

Gitflow Workflow

如果你拿出与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. Trunk / Main分支
   • 构建和自动化测试都没问题
   • 没有未完成的工作（如果更改需要多次提交，请使用功能分支）
   • 准备成为候选发布者（如果更改引入任何阻止程序，则不会在此处提交）

2. 功能分支

   如果功能或修复需要多个提交，则创建
   • 特定功能或错误修复的分支
   • 一切都被允许：破坏构建，测试失败
   • 最终合并到主干

   • 偶尔将trunk与其合并（以减少分支之间的偏差）

   在合并到主干之前

   • 应该清理所有内容

3. 稳定分支
   • 为每个要支持的版本创建
   • 匹配某些版本的trunk +稍后更改某些更改+ workarounds
   • 从此处创建用于手动测试的构建

工作流：

1. 小功能/修复：
   • 只提交到主干
2. 大功能/修复：
   • 创建功能分支
   • 在那里做多次提交
   • 合并到主干
   • 删除功能分支
3. 修复手动测试发现的错误：
   • 修复主干（＃1或＃2）
   • 合并到稳定分支
4. 解决方法（我们稍后会清理的快速和脏修复）：
   • 直接在稳定分支中修复
   • 不要合并到主干

我在SVN和TFS上使用它，它似乎没有产生问题。由于所有分支都是从主干创建的，因此TFS应该没有合并问题。