TFS2011的合并功能与Git的对比

全新的差异/合并体验—我们过去5年来发布的就是原始SourceSafe 差异/合并工具—大约在1994年我们还停留在One Tree 软件时创建。多年来它一直被增强，以支持全球化，Unicode等，但它本质上是同一个diff工具。不过现在不再是了，都已经过去了。我们在VS编辑器的基础上新建了一个差异/合并体验。在你说“等等，我真的很喜欢kdiff！”之前，请不用担心——这仍然是可配置的，你可以使用自己喜欢的任何工具，但是话说回来，这次真的变得更好。为什么说它更好了呢？

• 它同时支持“内联”和“并排”模式，你可以选择自己最喜欢的模式。
• 它有句法高亮提示（VS编辑器中支持这个）
• 单行中的个别变更会有高亮提示
• 当同时进行比较和合并时，你可以利用VS编辑器的强大力量，包括其中的撤销，智能感应和其他功能。
• Diff有一个很棒的“迷你地图”。
• 现在你可以在视图中做更多的操作了（比如历史等等。）
• Diff使用VS中全新的临时标签功能，以免弄乱你的文件。
• 手动选择合并方案的改进方法。
• 打开/关闭忽略空格的互动方法。

这里有些屏幕截图来展示这些功能，你会注意到很多我上述列举的优点：

临时标签中的并排差异视图（一直到右边），左边有变更高亮��示槽，同行内变更高亮提示，VS风格类/方法导航，句法上色等。没错在源代码上方文件名的文本看上去很傻，那是一个错误。

使用内部模式的相同diff：

以下是一些关于合并的截屏。我把你可以选择的三种视图都包含在其中了：

总的来说，这是一款比我们以前更好的默认差异和合并体验。

合并时最少化冲突—这大概是我们听到过的最大的关于合并的抱怨了，它的方式太麻烦了。我们花了很长时间来努力研究这个反馈，总结出首要的问题是做合并时会有太多冲突报告，而这些报告没有要求你做有意义的决定。大家希望它“处理”所有明显的合并并提请他们注意哪里他们有真正的工作要做。

为展示TFS 2010和TFS 11间的区别，我运行了一个示例场景。它很简单，而且看上去有点刻意为之，但却能显示出其中的差异。我选取了一个充满TFS源代码的文件夹，并为它加分支。然后我在两个分支中把两个方法进行了重命名，并合并了结果。结果是源代码分支中48个文件改变了，而在目标分支中有90个文件改变了。结果报告中的冲突如下：

• TFS 2010: 38 个冲突
• TFS 11: 12 个冲突

差别在于TFS 11自动解决了26个冲突，无需经过用户交互。

我总是听说Git是这种行为的“黄金标准”。所以，我们对Git和TFS合并行为做了一个点对点的比较，我们发现为了向Git体验看齐所必需的代码改动真的很小。所以我们比较了新版TFS和Git。我不想说这是耗费精力的测试，或者说我面面俱到，但我相信它覆盖了大部分常见情况，当你亲自体验时，如果发现我们遗漏了什么，请让我知道。

针对这个情况，我想比较不同冲突的行为。我创建了一个含有9个文件的文件夹，并进行了分支，然后安排了一个特定模式的变更，以激起冲突。以下就是变更：

File	Source change	Destination change	Comment
file1.txt	unchanged	unchanged	Trivial case, nothing to merge and nothing in the destination
file2.txt	edit line 3	unchanged	Just merge the change into the destination
file3.txt	unchanged	edit line 3	Nothing to merge over and the change in the destination should affect it
file4.txt	edit line 3	edit line 7	Distinct changes in source and destination
file5.txt	edit line 5	same edit line 5	Same change in both files should merge well
file6.txt	edit line 5	different edit line 5	This is a conflict that will require user interaction to resolve
file7.txt	delete file	unchanged	Delete the file in the source an no changes in the destination
file8.txt	delete file	edit line 5	A file delete in the source conflicting with an edit in the destination
file9.txt	rename file	unchanged	Should not really be any conflict here

然后我在TFS 2010，TFS 11和Git中创建了同样的场景，并查看结果。在这个场景中，我对三个产品都使用了命令行。

以下是TFS 2010的合并输出：

注意其中列出了3个冲突，还有4个额外的合并。文件1和3无需任何兼并。以下是tf状态输出：

我们可以看到有7个变化有待解决（期望的，基于我们在合并输出中看到的）

以下是同样场景中Git的合并输出：

以下是状态输出：

首先要注意的是Git只显示了2个冲突—文件4被自动解决，而在TFS 2010中并没有。我还注意到文件5完全没有显示（记得那是源代码和目标中发生相同变化的地方）。除此之外，合并/冲突结果是相同的。我还注意到TFS合并输出的外形不易于阅读，Git中的着色代码更好，而且还在状态输出中包含了冲突信息，这也很不错。

然后我在TFS 11中运行了同样的场景：

现在冲突的数量和Git相同。我们在显示文件5.txt上还是存在差别的，因为我们在合并上做的借记/贷记逻辑需要待决定定的变化来辨认合并已经发生。我要更留心地看看它。输出是相同的，我也和团队说了要在这里做一些改进，以提高可读性，减少冗长。

当我在做与Git的比较时，我很惊讶的发现我们在2010中解决的冲突种类数量没想象的那么高。不过，还没把频繁度算进去（所以我才先做了一个重命名。）我们没有处理的一个类型正好是最常见的，所以对开发者来说小小的变化就会产生很大的影响。

UI中无基合并—还有一个大家一直都很希望解决的就是希望能在UI中实行无基合并。我们在命令行中支持这个，当我也很多次在Power Tools的博文中说到过回滚这个问题，对很多人来说，不在UI中就等于不在产品中。现在UI中也有了。当你从源代码控制管理器中启动合并时，会有一个浏览器按钮，你能通过它来找到分支以完成无基合并。

我们来看一个例子。我从这样的分支结构着手：

你会发现在destination和AlternateDestination间没有合并关系。但让我们来想象一下我在destination中有一些改变，我想在AlternateDestination中有相同的改变，但我又不想通过Source来实现。我希望从destination到AlternateDestination做无基合并。我现在就可以转到源代码控制管理器，开始标准合并体验了。

一如往常，在列表中只有Source，这是唯一和destination相关的分支。然而，和TFS不同，现在有了一个浏览……按钮，达成无基合并。如果你点击它，你会得到：

在这里你可以看到我可以选择AlternateDestination。如果我选中，并点击确定，我就会回到向导：

而且它警高我，我正在做无基合并，但是我可以点击下一步，然后完成并继续进行。所以，你现在可以在UI界面中做无基合并了。

未搁置上兼并—从一开始人们就喜欢搁置，把它看做是打包变化并将其放在一边的一个简单干净的方法。然而，我们经常听到抱怨无法搁置待定改变到工作空间，无法处理合并冲突，这是个严重的限制。现在不会了！我们把合并融入了未搁置操作，它用起来就像在产品的任意地方进行合并一样。

这篇博文写得已经很长了，所以我也不再发这一点的截屏了。在这个场景中新版功能如下，合并被执行了，冲突也被提交了等等。所有周边的UI与合并发生的其他场景中（像合并与获得）一样。