使用 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. 主干/主分支
   • 构建和自动化测试都可以
   • 没有未完成的工作（如果更改需要多次提交，请使用功能分支）
   • 准备成为候选版本（如果更改引入了任何阻止程序，则不会在此处提交）

2. 功能分支

   • 在一项功能或修复需要多次提交时创建
   • 特定功能或错误修复的分支
   • 一切都允许：构建失败、测试失败
   • 最终合并到主干

   • 偶尔会合并主干（以减少分支之间的偏差）

   • 在合并到主干之前，所有东西都应该清理干净

3. 稳定分支
   • 为要支持的每个版本创建
   • 匹配主干的一些修订 + 稍后合并一些更改 + 解决方法
   • 从这里创建用于手动测试的构建

工作流程：

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

我在 SVN 和 TFS 上使用过它，它似乎没有造成问题。由于所有分支都是由主干 TFS 制成的，因此合并应该没有问题。