TFS 11中的合并增强功能

原文发表地址 Merge enhancements in TFS 11

原文发表时间 31 Aug 2011 11:31 AM

这是我“开发者都是狂热的粉丝”系列的下一篇博文，说的是TFS 11中即将到来的增强功能。我的上一篇博文是关于工作区改善。

我们在TFS 2010中收到的常见客户反馈信息，都说合并还是太复杂了，并且/或者说太有限了。我们已经在即将发布的版本中做了一些显著的改进：

全新的差异 / 合并体验—我们过去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个文件的文件夹，并进行了分支，然后安排了一个特定模式的变更，以激起冲突。以下就是变更：

然后我在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与合并发生的其他场景中（像合并与获得）一样。

呵呵！已经说得很多了，但其实我还有很多想讲的，我会在这个系列中继续写博文的。

Brian