我想出了一个办法来解决它。所以重新迭代，我认为问题是我想要的更改是在 Dev2 中，但是我在创建 Dev2 后回滚了 Dev，所以回滚是最近的更改，所以合并想要保留回滚并删除我想要的更改远离 Dev2。所以我得出的结论是，我需要以某种方式将这些更改再次应用到 Dev2，就好像它们是一个新的编辑一样。
所以我做的是：
- 将变更从 changeset1 移到 Shelveset
- 将 Dev 合并到 Dev2，从而删除所需的更改
- 将 changeset1 Shelveset 取消搁置到 Dev2
#1 是最难的部分。首先，我创建了两个新工作区：DevC0 和 DevC1。我将 changeset1 之前的变更集拉到 DevC0 中，并将 changeset1 拉到 DevC1 中。所以现在 DevC1 拥有我感兴趣的所有更改，而 DevC0 没有。然后，我将所有更改的文件（使用 BeyondCompare，但我认为您也可以将除 TFS 文件夹/文件之外的所有文件）从 DevC1 复制到 DevC0。然后在命令行中，我在 DevC0 文件夹上做了一个tf vc reconcile，让它能够识别我刚刚复制过来的所有更改。例如。 （在我的情况下，我实际上并不想要/deletes）：
tf vc /reconcile /promote /adds /deletes /diff /recursive [DevC0 itemspec]
（确保命令提示符的工作目录是映射到目标工作区的目录）。之后，所有差异现在都显示为 Visual Studio 团队资源管理器/源代码管理资源管理器中的未决更改。所以我可以从那里创建一个 Shelveset。
#2 只是从 Dev 到 Dev2 的典型合并。它删除了所有更改并使 Dev2 与 Dev 匹配。我不知道在应用 Shelveset 之前是否需要签入，但我做了。
#3 我的 changeset1 更改在我的 Shelveset 中，但 Shelveset 属于 Dev 分支。幸运的是，Team Foundation Power Tools 可以将 Shelveset 取消搁置到不同的分支。例如：
tfpt unshelve /migrate /source:"[Dev server path]" /target:"[Dev2 server path]"
这会打开一个窗口，其中包含每个文件的合并选项。我手动查看了前几个，然后尝试自动合并所有。这相当于通过 Visual Studio 进行合并 - 它在可能的情况下自动合并，并在同一个窗口中将冲突留给我。在那之后，似乎所有需要的更改现在都在 Dev2 中等待更改，我将它们签入。
然后我尝试从 Dev2 合并回 Dev 只是为了看看它是否会正常运行，它确实将所有更改合并到 Dev 并将原始回滚删除的许多更改标记为未删除。目前，我撤消了该合并中的未决更改，直到我们真正准备好将此工作子分支合并到我们的主开发分支中。