1

几周前我的唯一一位同事离开了，我现在必须将所有内容合并在一起，为我和我的新开发人员创建一个基线工作环境。我以前的同事完成了与我们的 Team Foundation Server 相关的大部分管理工作。

我目前的结构由 4 个分支和一个 Bugs 分支组成。分支 A 和分支 B 是我们独立的开发分支，它们是从中央开发分支（分支 C）分支出来的。中央开发分支（C 分支）源自主分支（D 分支）。Bugs 分支不应该影响我的问题，所以它应该保持未命名。

前段时间我在尝试将所有内容合并在一起时犯了一些错误，因此我已恢复到分支 A、分支 B 和分支 C 的工作版本。

既然我已经获得了分支 A、B 和 CI 的工作版本，我想开始将分支 A/B 合并到 C 中。我想，因为我在技术上没有使用最新的代码，而且我已经恢复到旧版本我可能必须将“版本类型”更改为“最新版本”以外的其他内容。

版本类型

我应该更改版本类型，还是应该将其保留为最新版本并继续合并？

4

2 回答 2

2

当我阅读问题时，分支结构如下所示：

D (Main) 
--C (Dev)
----A (Developer1)
----B (Developer2)
--?Bugs

快速术语（所以我可以使用简短的符号）：

  • FI = 正向集成（从父分支到子分支）
  • RI = 反向集成（从子分支到其父分支）
  • 分支 C 是分支 A 和分支 B的父级。A 和 B 是C的子级。

从最初的问题来看，听起来存在以下状态：

  1. A 和 B 都具有尚未 RI 到 C 的更改。
  2. 您恢复了以前在 C、B 和 A 中的合并尝试。
  3. （？）您在每个分支中提交了回滚（使用 tf.exe 回滚...），因此当您从每个分支“获取最新”时，您将拥有您的工作版本而不是失败的合并版本。

这是我的建议：

  1. 回滚到 A、B 和 C 的稳定版本（如果您还没有的话）。
  2. C->A，测试，A->C，验证OK。
  3. C->B，测试，B->C，验证OK。

细节：

  1. tf 回滚到 A、B 和 C 的工作版本（如果您还没有这样做）

  2. FI 从 C->A（C 到 A）

    • 解决你能解决的所有冲突

    • 为待处理的合并 创建一个搁置集
    • 现在在 A 中测试，
      直到您确信合并成功并且您已经让所有 C 与所有 A 一起工作。
    • 将合并更改提交给 A。

  3. RI 从 A 到 C，

  4. 重复步骤 2 和 3，从 C->B，然后 B->C

提示： “A”可以是具有最简单或最重要更改的开发人员分支。

* 如果您决定不提交更改以回滚到您之前的“稳定”版本，那么您可能需要使用版本类型选项...但是如果所有三个分支都有需要回滚的更改，那么您至少需要回滚 c，然后合并以前版本的 A。我个人更喜欢从所有 3 个分支开始，它们的最新版本是您要继续使用的工作版本。（合并已经足够棘手，无需合并到特定的变更集）。

您描述的场景很常见，但不是最佳的。如果 A 和 B 都经常与 C 进行合并（在每次进行 FI 和测试之后），那么您的合并任务将会小得多。

向前进

我的一些建议可能会减少您未来的合并痛苦。

  1. 对于日常工作，开发人员可以将TFS 搁置集用于待处理的更改，然后直接检查到公共开发分支。仅当您需要隔离时才需要完整分支（例如同时处理冲突更改或多个开发人员处理重大更改）
  2. 仅当您需要与其他开发人员更改隔离时，才从公共开发人员分支创建子分支。例如，如果您正在实施需要两个开发人员共同处理的重大更改，您可以创建一个“功能”分支，一个或两个开发人员可以在不破坏开发人员分支稳定性的情况下处理该功能，然后尽快合并回 Dev 分支功能稳定。
  3. FI 经常从父级合并到子级！否则合并变得非常难以协调。

对于团队的规模，您可能有太多的分支（除非您有不应并排存在的并行功能）。理智会随着您远离 Main 的分支数量而降低。我会让所有开发人员从单个 Dev 分支 (C) 中工作，然后仅在需要时创建一个短暂的功能分支（然后在功能足够稳定以合并到 Dev 分支时关闭分支。

TFS 分支指南是一个很好的资源，提供漂亮的分支模式图片和许多指导，包括可能更好地满足您未来需求的不同模式。

享受！-泽潘

于 2011-06-28T15:42:34.090 回答
1

如果 A 和 B 是开发分支（我的意思是在主开发中单独添加新代码/功能的分支）从 C 中创建并且它们已经到了生命的尽头，那么它们需要重新集成回 C . 将最新版本的 A 或 B 合并到 C 中是正确的做法。

于 2011-06-27T22:28:39.687 回答