0

因此，几天来我一直在摸索，试图想出一种有效的方法来管理 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_2to QA_Release_1。

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

所以我想第一个问题是我们这样做会给自己带来多少合并麻烦（如果有的话）？是否可以忽略巨大的合并并在重新调整时解决大量冲突？

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

编辑：我想念git ...

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

Gitflow 工作流程

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

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

问题是，TFS 不喜欢跳过分支。只要您不合并父级或子级，就将其视为毫无根据的合并。因此，由于QA_Release_1是在 下创建的Develop，它不会轻易合并到Main. 这让我回到我的第一个问题：毫无根据的合并是一个陷阱吗？

4

1 回答 1

0

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

分支机构：

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

  2. 功能分支

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

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

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

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

工作流程：

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

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

于 2016-06-22T05:50:38.330 回答