在代码版本中来回还原时要选择哪种版本类型+；TFS VS2010 我的一个和唯一的同事在几个星期前离开了，我现在必须把所有的东西合并在一起，为我的新开发人员和我的前同事做了一个基本的工作环境。我的前任同事已经完成了与我们的Team Foundation Server有关的大部分管理。

我当前的结构由4个分支和一个bug分支组成。分支机构A和分支机构B是我们独立的开发分支机构，它们是中央开发分支机构（分支机构C）的分支机构。中央开发分支（C分支）源自主分支（D分支）。Bugs分支不应该影响我的问题，因此它将保持匿名

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

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

---

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

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

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

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

快速术语（因此我可以使用简短的表示法）：

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

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

A和B都有未更改为C的更改

您恢复了以前在C、B和A中的合并尝试

（？）您在每个分支中提交了回滚（使用tf.exe rollback…），因此，当您从每个分支“获取最新版本”时，您拥有的是您的工作版本，而不是失败的合并版本

这是我的建议：

回滚到A、B和C的稳定版本（如果还没有）

C->A，测试，A->C，确认OK

C->B，测试，B->C，确认OK

详细信息：

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

FI从C->A（C到A）

• 尽可能解决所有冲突
• 为您的应用程序创建搁置集
  待合并
• 现在在A
  直到你确信合并成功 成功的话，你就可以让C和A一起工作了
• 将合并更改提交到

从A到C

重复从C->B到B->C的步骤2和步骤3

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

*如果您决定不提交更改以回滚到早期的“稳定”版本，那么您可能需要使用版本类型选项。。。但是，如果所有三个分支都有需要回滚的更改，那么您至少需要回滚c，然后合并以前版本的A。我个人更喜欢从所有三个分支开始，让它们的最新版本成为您想要继续进行的工作版本。（在不必合并到特定变更集的情况下，合并已经足够复杂了）

您描述的场景非常常见，但不是最优的。如果A和B都频繁地合并到C（在每次进行FI和测试之后），那么您的合并任务就会小得多

---

前进

我有几条建议可以减少你将来合并的痛苦

对于日常工作，开发人员可以对其挂起的更改使用TFS搁置集，然后直接签入公共开发分支。只有当您需要隔离时（例如，同时处理冲突的更改或多个开发人员处理中断的更改），才需要完整分支

仅当需要与其他开发人员更改隔离时，才从公共开发人员分支创建子分支。例如，如果您正在实现一个突破性的更改，需要两个开发人员都参与其中，那么您可以创建一个“功能”分支，一个或两个开发人员可以在不破坏开发人员分支的情况下参与该功能，然后在功能稳定后立即合并回开发人员分支

FI经常从父级合并到子级！否则，合并将变得非常难以协调 对于团队的规模，您可能有太多分支（除非您有不应该并排存在的并行功能）。健全性随着离开主分支的数量而降低。我会让所有开发人员使用单个开发分支（C），然后只在需要时创建一个短期功能分支（然后在功能稳定到足以合并到开发分支时关闭该分支）

这是一个很好的资源，可以获得漂亮的分支模式图片和大量的指导，包括可能更好地满足您未来需求的不同模式

---

享受！-Zephan

你也可以集成C->A和/或C->B，首先验证这些区域是否正常工作。这通常比反向集成到共享区域然后验证结果更可取。因为你是一个人，所以从A->C或B->C开始可能不会有什么伤害。此外，你实际上正在使用最新版本在这个选择中，你要说的是，将我所有的变更设置设置到并包括我当前分支（ex B）中最新的变更设置，并将它们合并到目标（ex C）中。