Team Foundation Server原理
有人说建立分支很简单，但是合并起来确实很受伤。在我看来这话确有道理，尤其是那些对于离开主干很久的分支。下面的做法对开发小组来说通常是个不错的办法，按照一个常规的原理定期合并代码，只要确保不出现令人厌恶的千奇百怪就行。
从技术的角度看，执行代码合并没什么困难的。第一步你需要在源文件控制窗口中选择你想要合并的分支，然后从上下文菜单中选择合并，这将会弹出一个向导对话框，帮助你晚场合并过程。
如果你毫无根据的进行合并，向导将会阻止你的操作。比如，你将在一个源文件树中没有直接祖先关系的两个位置的代码进行合并，这时向导就会阻止合并。这限制大多数工具存在，因为这将导致复杂性和迷惑性。然而，如果你确实想要执行无根据的合并，请考虑试用一下Team Foundation Server的动力玩具。
合并操作过程中几乎没有不发生冲突的，因此当TFS检测到冲突时，会弹出一个对话框，需要开发人员选择进行哪个改变。
理想情况下，你可以选择自动合并全部，然后去喝杯咖啡，但是依我的经验看来，这样做并不怎么聪明，自动合并有时会出现莫名其妙的选项。所以我更喜欢手工合并每个文件。
对于大量复杂的合并操作，我建议将小组核心开发人员带到一个配有投影仪和膝上电脑的房间，让他们一起完成合并工作，因为这个过程需要他们的集体智慧。
自动生成
在执行生成时，我始终认为要坚持这样一个基本依据，那就是要保护代码库的安全。在Team Foundation Server中支持这一特性的是Team Build系统，该系统扩展了MSBuild的功能，支持将生成任务分配到一个或多个生成服务器上完成。
TFS中的每个生成被注册成Team Build类型，该类型定义了生成必须执行的各种参数。其中必须指明的参数包括生成类型名，在版本控制中的那个解决方案将被生成，什么样的配置（例如X64 Release），使用哪台生成服务器以及生成结果存储在何处。也可以将自动测试包含到生成中，测试包括代码覆盖和静态代码分析。
一旦创建了Team Build 类型，生成脚本就可以用来订制执行一些向导中不支持的额外操作。Team Build类型和Team Project始终存放在版本控制存储器中明显的地方，例如，如果我的生成类型名为：“TrunkHelloWorldSolutionC
剔除和管理生成
Team Explorer通过分析版本控制存储器组装Team Project树上的Team Builds节点，决定定义了那些Team Build类型。呈交的每个节点都可以用来剔除一个生成。
Team Foundation Server利用指定的生成服务器管理通讯，并提供一个生成进度摘要。这对于很长的生成来说非常有用，因为这样可以看到生成进度情况。生成完成后，生成摘要随即转换成一份详细的生成报告，该报告将会显示生成过程中发生些什么以及用到了那些改变集和工作项。
双击Team Explorer中的Team Build 类型，所有以前的生成将会被重新找回，并且每个都会有一个质量状态指示器。通过这种方式，我们可以使用Team Build 系统来管理生成过程，尽管很多人还没有认识到这是Team Build 系统有意为之。
我们可以利用一个特别的生成返回工具从报告某个问题的过程中返回。通过代码和所有其它方式返回到需求。从工具集成的角度来看这是一个巨大的进步，也是高集成度对开发小组有所帮助的生动例子。
