我们已经遇到了不止一次这种情况，现在认为这不是偶然事件。当我们完成分支后进行合并时，有比应该更多的更改。因此，大多数显示为待处理更改的文件从未更改过（在大多数情况下，既没有在分支中也没有在基础版本中）。当我比较它们时（我使用Beyond Compare），它们没有任何区别。我还没有检查完所有未更改的文件，但在大多数情况下，它们似乎被标记为[merge]，而实际更改的文件则标记为[merge,edit]。
在某些情况下，我们可能更改了约100个文件，但待处理更改显示超过22,000个更改。我们试图在某个时间点将它们检入，以为TFS足够聪明，能够知道哪些文件更改了，哪些没有更改。但它检入了所有文件。有人知道发生了什么问题以及如何解决吗？
我们正在运行的是 TFS 2012 w\ Update1
每个人都在使用 Visual Studio 2012 w\ Update 1。
如果有人遇到同样的问题，一个解决办法是撤销您的待处理更改。当您收到确认对话框时，请选择“全部不要”。只有您的待处理更改应该保留。
关于您更改了100个文件，而TFS要合并数千个文件的问题。通常是由于重命名（或删除然后取消删除，或移动）分支所致。这已经让我受过几次伤，我理解您的痛苦。
我能给出的最好建议是，一旦创建了一个分支，请不要再动它。不要移动它，也不要重命名它。如果分支的位置或名称不正确，请忍耐到删除分支并创建新分支的时候再处理。
因为TFS 201x在幕后工作的方式，更改分支的根文件夹实际上会将其变成不同的对象。当您再次尝试合并分支时，TFS将执行无基础合并，这实际上意味着所有分支中的文件都已更改（即使它们没有）。这是新行为，旧版本的TFS（2005/2008）不会遇到这个问题。
例如，您有一个Team Project看起来像这样
$/TeamProject/Main
然后您从“Main”创建了一个名为“Dev”的分支
$/TeamProject/Dev
$/TeamProject/Development/Dev
$/TeamProject/Dev下（您可以通过转到“工具”，“选项”，“源控件”，“Team Foundation Server”，然后检查“在源控件中显示已删除的项目”设置来查看此内容）。
名为$/TeamProject/Development/Dev的文件夹实际上是全新的！因此它与“Main”没有合并关系。但是令人困惑的是，IDE将显示一个关系，但实际上它不存在。第一次从$/TeamProject/Development/Dev合并到$/TeamProject/Main时，TFS将执行一个巧妙的无基础合并以建立分支关系。
如果重命名分支，则会发生相同的事情（旧分支将被删除，并在其下创建一个新分支）。
这个博客更详细地介绍了一些内容
在撤销确认对话框中选择“全部不要”选项的评论可以正常工作，但是Mark Hosang指出，如果你有新文件，这种方法就无法正确工作。Mladen Mihajlovic提到了确保不选择这些新文件的方法。但是，对于一个大型代码库来说，浏览这些文件非常繁琐。
因此，我的方法是：在进入确认对话框之前，您将看到一个窗口，以选择要撤销的文件。此窗口具有可排序列。您可以按“更改”列排序，并仅选择具有“合并”状态的文件（这些是未更改的文件；“合并，编辑”是已编辑的文件，“合并，分支”是新文件）。只需选择它们，然后点击“撤销更改”，就可以享受一个没有杂乱无章的合并更改集的美好。
根据我的经验，当TFS在分支A中的文件A和分支B中的文件B之间没有关联时，就会出现这种情况。
在合并分支时，如果文件之间没有关联，TFS总是会创建一个关联。因此，它想要以“合并”的方式进行检入，以记住这些关系。
当我不需要这些关系（例如重新父子化）时，我倾向于撤销这些“合并”更改。