与其他服务器相比，Team Foundation Server 的分支特性有哪些区别？

Question

TFS的分支特性是什么？

早期分支/重量级分支：

如果我们看一下Perforce、Subversion、CVS等工具，我们会发现分支是对主干进行复制。无论这些文件在该分支中是否被更改，它都是“早期分支”所有定义为分支的文件。

该方法开始为整个文件树创建文件的新版本，即在决定创建分支的时间点。

最大的缺点之一是，您要将在该分支之外（通常在主干上）进行的任何更改带入该分支，都需要向内部合并这些文件的每个文件合并，因为它们已经“早期分支”。

晚期分支/廉价分支：

与较新的工具 - 例如 - ClearCase、Plastic SCM、AccuRev、Mercurial、Git相比，我们看到了一个晚期（廉价）分支策略。

我们看到，在分支上检查文件时才会首先创建分支中的新版本。

这意味着当您希望将主干上的更改重新基于到您的分支时，不会发生未更改文件的合并。

TFS如何表现？

注意事项：当考虑DVCS工具时，我的术语不是很准确。我认识到Perforce有一种绕路的方式来覆盖视图，但这并不是没有巨大的劳动。

- polyglot

Answer 1

我被告知TFS更接近前者而非后者。

- James Polley

---

这是非常正确的 - 在TFS中一个分支“需要一些时间”，用更好的词语来形容。它们相当重。 - Nicolas Webb

Answer 2

注意: 版本控制（前身为分支和合并）指南 可以在这里提供帮助。

在 TFS分支指南-Lab.zip 文件的 "单一开发团队场景2.0.pdf" 文档中，您将看到创建分支后会进行提交（检查所有来自原始分支的文件）。如 隔离协作 页面所述，空间利用率被最小化：

“当您创建新分支并提交时，新分支中与源分支中相同的所有文件都指向相同的内容。结果是分支仅消耗极少的额外存储空间，并且仅当分支文件与源文件不同时才扩展存储空间。即使文件发生更改，Team Foundation Server 也会使用差异引擎分析文件之间的变化，并再次优化存储空间。”

因此，这是 TFS2008 的重型分支（具有空间优化）。

在 TFS2010 中，分支是一流的对象，并且与简单文件夹容易分离。

- VonC

---

至少这是一个重大的改进。他们网站上的分支计划相当不成熟。示例应该有一个名为dev和一个名为release的分支，并且很少提到将它们撤下。更好的方法是为每个发布创建新的分支，以便于合并算法处理正确，并拥有一个不是3年前的共同祖先，例如。 - polyglot

实际上，在http://www.codeplex.com/BranchingGuidance/上有相当多非常有用和详细的指导。上述网站是对我在此提到的原始指导的重新审视。实现分支的所有技术都适用于版本控制系统。一些系统使这些技术的某些方面更容易，但它们通常可以应用于整个系统。 - Ryan Cromwell

@Ryan Cromwell，感谢您提供的另一个链接。我现在在我的编辑答案中参考了这两个指南。 - VonC

@polyglot：我完全同意你的分析。可以说，TFS分支模型并不是最优秀的选择 ;) - VonC

@AmittaiShapira 感谢您的编辑，更新了那个链接。 - VonC

Answer 3

我曾在TFS上工作了5年，最近一年转向GIT。

TFS有两个主要的劣势（与GIT相比）：

1）没有Rebase概念。所有的分支交互都是合并。合并会破坏变更集历史，并将所有有用的细节隐藏在提交注释中。没有Cherry-pick，没有时间线重建。这导致无尽的父级遍历和严肃的研究才能确定一个变更集的历史。

2）基于无基础的合并是一场噩梦。在TFS中，如果你在6个月前没有建立分支关系，你将不得不反向/正向集成多次才能到达目标主干。在git中，所有的主干始终兼容。

TFS可以工作，但也存在障碍。其中一些障碍真的伤害了我们的交付时间表。

到目前为止，我们在敏捷团队环境中使用GIT做了一些非常高级的事情，并且总是能够在几分钟内解决每个新的源问题，而不是需要几个小时或几天。推广的层次是抽象的，可以随意交换。开发人员可以“节点对节点”共享变更集，并在推送到公共存储库之前协作工作。

没有冒犯微软的意思，但我无法支持一个有这么多障碍的工具。

- Todd

Answer 4

当你在TFS 2008中创建一个分支时，你必须先检入新的分支文件。一旦你检入了这些文件，分支的版本控制就会与原始版本分开。 你也可以跟踪分支文件在分支之前的历史记录，但你需要安装TFS Follow Branch History Add-in for VS插件。

- Branislav Abadjimarinov