分支特性，与其他特性相比

Question

TFS的分支特性是什么？

早期分支/重分支

例如，如果我们查看工具Perforce、Subversion、CVS，我们就会发现分支正在获取主干的一个副本。所有被定义为分支的文件都是“早期分支”，不管这些文件是否在该分支中被更改。

此方法在决定创建分支时开始为整个文件树创建新版本的文件。

最大的缺点之一是，在该分支之外(通常在主干中)所做的任何更改，如果要将这些更改带入分支，都需要将这些文件内部的每个文件合并，因为它们已经“早期分支”。

后期分支/廉价分支

与较新的工具--例如ClearCase、塑料SCM、AccuRev、Mercurial、Git --相比，我们看到了一种晚(廉价)的分支政策。

我们看到，只有在分支上签入文件时才会创建分支中的第一个新版本。

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

TFS的表现如何？

注意:当我们考虑DVCS工具时，我注意到我的术语并不准确。我认识到Perforce有一个全面的方法来叠加观点，但是如果没有巨大的努力，这是不可能的。

Answer 1

注意：版本控制(除分支和合并)指南可以在这里提供帮助。

在TFS分支指南- Lab.zip文件的“单个开发团队场景2.0.pdf”文档中，您将看到创建分支之后是提交(检查原始分支中的所有文件)。

所使用的空间被最小化，如隔离用于协作页面中所描述的：

创建新分支并提交时，新分支中与源分支中的文件相同的所有文件都指向相同的内容。 结果是，分支占用的额外存储空间很少，只有当分支文件与源文件不同时，存储空间才会扩展。 甚至当文件更改时，也使用一个差异引擎来分析文件之间的更改，并再次优化存储空间。

因此，对于TFS2008 (空间优化)来说，这是一个很大的分支。

在TFS2010中，分支是第一类对象，很容易从简单文件夹中分离出来。

​

​

Answer 2

我在TFS工作了5年，最近在去年改用了GIT。

TFS有两个主要缺点(vs )：

1)没有重新定位的概念。所有分支到分支之间的交互都是合并的。合并筛选器更改集合历史记录，并在提交注释中隐藏所有有用的详细信息。没有樱桃-选择，没有时间表重建。这就导致了家长们无止境的散步，以及认真的研究来确定一个变化的历史。

2)无根据的合并是一场噩梦。在TFS中，如果没有在6个月前构建分支关系，那么需要多次反向/转发集成才能到达目的地主干。在git中，所有的中继始终是兼容的。

TFS工作，但有路障。一些路障真的破坏了我们的送货时间表。

到目前为止，我们已经在敏捷团队环境中使用GIT做了一些非常先进的事情，并且总是能够在几分钟而不是几小时或几天内解决每个新的源问题。晋升的层次是抽象的，可以临时交换.开发人员可以共享变更集“节点到节点”，并在进行公共回购之前在工作上进行协作。

无意冒犯微软，但我只是无法在有这么多障碍的工具背后开箱即用。

Answer 3

在tfs 2008中创建分支时，必须首先签入新的分支文件。一旦您在分支的版本控制中检查了它们，就会独立于原始分支启动。您还可以在分支文件之前跟踪它们的历史记录，但是需要安装TFS遵循分部历史记录为VS添加。