TFS 2012 重新应用变更集中的变更以实现持续集成答案

【问题标题】：TFS 2012 Re-apply changes from a change set for continuous integrationTFS 2012 重新应用变更集中的变更以实现持续集成
【发布时间】：2016-12-19 11:06:58
【问题描述】：

我在 TFS 2012 中有一个项目，并使用 TFS 进行源代码控制。我只有一个代码分支。

我想为以下场景找到一个简单的解决方案。

这是一个包含六个变更集的示例分支。

这就是故事到目前为止的发展方式（假装用户不是我的全部！）

5219 开始构建和测试运行。
发生了许多变化（5220、5221 和 5222）。
5219 的测试运行结束，我们是绿色的 - 都很高兴。
然后，我们的 CI 运行 5222 的测试运行。它变红了。因此我知道我的问题出在 5220、5221 和 5222 中的一个（或任何一个）上。
作为程序问题，我们回滚到最后一个已知的绿色 (5219)
经过一番调查，负责 5220、5221 和 5222 的每个人都收到了他们的产品积压项目 - 一切都很好，我们发现了一些关于我们的更改的新内容（即它破坏了我们没有预料到的东西） .
因为我们是绿色的，所以发生了另一件工作 (5235)。

到目前为止一切都很好，但是被归还 5221 的人会怎么样。

我希望他们做的是让他们了解最新的任何当前更改，然后重新应用 5221 更改集中的更改（就像在 subversion 中一样）。

我可以使用 powertools tfpt getcs 命令找出如何“获取”更改集 5221。这给了我一个不同的工作区和服务器版本文件，但不尝试任何类型的合并。我可以弄清楚如何为分支“获取此版本”，这将使整个分支回到那个时间点。我不知道如何将作为 5221 的一部分发生的更改合并到最新版本中（但对我来说仍然是本地版本）。

有什么想法（除了升级我的 TFS 和摆脱 TFS 源代码控制 - 这会发生，但不会在很短的时间内发生）？我也希望避开多个分支。我的实际项目是大型的、单一的，并且在 TFS 中的分支不太友好。

【问题讨论】：

标签： tfs

【解决方案1】：

使用门控签入而不是回滚更改。门控签入将自动拒绝导致构建损坏的任何更改。

【讨论】：

感谢丹尼尔的回答。不幸的是，由于项目的性质，CI 测试（主要是验收测试）需要数小时才能运行。我们不想阻止人们签入代码，因此我们不能为每次签入设置门禁，甚至无法为每次签入运行 CI 测试。因此，构建比 CI 运行更多，这意味着对于红色管道，有许多候选者可能会破坏它。当然，我们会为单元测试设置门（这要快得多）。

【解决方案2】：

恐怕您需要手动将 5221 中的更改更新到最新版本。没有自动的方法。

将最新版本导入您的工作区，将变更集 5221 与最新版本进行比较，然后将 5221 的差异复制并粘贴到最新版本，然后签入到 TFS。

【讨论】：

Cheers Cece - 几乎完美运行（好吧，我说得很完美 - 你知道我的意思）。如果我将目标路径类型更改为本地路径（在获得最新版本之后），那么我可以使用比较窗口来复制内容。能够使用一个体面的比较工具让我更容易编辑和复制，那就太好了。我会看看能不能插入一些东西，但这已经完成了我的大部分工作。