A 部分合并记录为只有变更集中的某些更改合并到目标。有两种常见的情况下面,你可以用部分合并结束:
方案1:撤消一些悬而未决的变化,当你正在检查的合并后的文件
在这种情况下,尽管我们已经合并变更Dev到Main,它仍然是合并候选人。这是由于合并引擎检测到该变更集中仍然存在一些变化,而这些变更未从Dev传播到Main。
方案2:演出在功能层面的合并无法从分支的顶部
例如:假设您拥有两个分支主要和开发,他们每个人都有两个文件夹( Feature1和Feature2),每个功能文件夹包含一个文件。我们从功能文件夹(Dev\Feature1\feature1.txt
和Dev\Feature2\feature2.txt
)编辑这两个文件并检入更改。
如果在特征1级进行合并操作。(Changset142→ Changeset143)您将在一个只在Feature1
文件夹中所做的编辑将被合并Pending Changes窗口通知。完成合并。
如果你看一看的优点1文件夹,你会看到的合并历史,从变更142所有的改变都被合并到变更143
但是,如果你看一看主要的合并历史您将看到变更集142中只有部分已合并到变更集143中。这是正常的,因为变更集142有一些更改 - 即编辑Feature2文件夹中的文件 - 未交付。
在部分合并的情况下,找出哪些更改已合并以及哪些更改从变更集中省略。实现此目的的唯一方法是对diff部分合并的变更集的内容以及作为合并结果生成的变更集的内容。更详细的信息可以参考本博客:Partial Merges in TFS – A Guide
更新
你可以做一个discard merge。 这必须从命令行完成。打开Developer command prompt, ,然后导航到任一分支下的文件夹(即将 导航到受影响的 workspaces之一)。 然后键入:
tf merge /r /discard "$/Project/B1" "$/Project/B2" /v:C12345~C12345
这将需要识别的变更(在这种情况下,它被变更集 #12345
),并更新它作为合并到目标分支(分支B2)。目标文件将被检出,但不会被更改 - 您只需检查它们即可完成操作。之后, 变更集将不再显示为合并候选人。您可以同时指定 一组变更集合,但它们应该是 连续的。
注意,这样做后,变更会偶尔还是会出现 作为合并候选 - 这是相当罕见的与最新 版本的TFS的,它几乎是不可能解决(除非你是 运行你自己的地方安装TFS并想让你的手在数据库中非常脏 )。如果您最终遇到了其中一个被拒绝的变更集,请忽略它。
来源: Finding merge candidates in TFS
我跑的变更集的比较,看看有什么不同。列出了4个差异。来自中继分支中目标40622的活动分支的变更集40621。现在我发现了这些差异,我该如何解决这个问题,以便变更集40621停止显示为合并候选人? –
您可以执行[放弃合并](https://msdn.microsoft.com/en-us/library/bd6dxhfy%28v=vs.100%29.aspx)。它不执行合并操作,但会更新合并历史记录以跟踪合并发生的情况。这会丢弃用于特定合并的变更集。** –
不幸的是,未从我的待处理列表中删除变更集。更改集31263位于待从Trunk合并到Active的待更改列表中。我运行了'tf merge/discard/version:C31263 $/Trunk/Project1 $/Active/Project1/recursive'。我检查了Active上的合并,然后再次调用合并对话框,31263仍在列表中。 –