与其他服务器相比，Team Foundation Server 分支特征
TFS有哪些分支特征？
早期分支/重分支
如果我们查看 Perforce、Subversion、CVS 等工具，我们会发现分支正在复制主干。它是“早期分支”所有定义为分支的文件，无论这些文件是否在该分支中发生更改。
当决定为整个文件树创建分支时，此方法开始创建文件的新版本。
最大的缺点之一是，在该分支之外（通常在主干中）进行的任何更改，如果您想要将其带入分支，则需要将每个文件合并到这些文件内，因为它们已经“早期分支”。
延迟分支/廉价分支
与较新的工具（例如 ClearCase、Plastic SCM、AccuRev、Mercurial、Git）相比，我们看到了延迟（廉价）分支策略。
我们看到，只有在分支上签入文件时，才会创建分支中的第一个新版本。
这意味着当您希望将其重新设置为分支的主干上发生更改时，不会发生未更改文件的合并。
TFS 的行为如何？
注意事项：我注意到，当我们考虑 DVCS 工具时，我的术语并不准确。我认识到 Perforce 有一种迂回的方式来覆盖视图，但是如果没有大量的工作就无法完成。
What are the branching characteristics of TFS?
Early Branching/Heavy Branching
If we look at the tools Perforce, Subversion, CVS, for instance, we see that branching is taking a copy of the trunk. It is "early branching" all of the files which are defined to be branched, irrespective of whether those files are changed in that branch.
This methodology starts creating new versions of files, at the time the decision to create a branch is made, for the entire tree of files.
One of the biggest disadvantages is that any changes made outside that branch (typically in the trunk), that you want to bring into the branch, require per-file merges inwards of these files as they have "early branched."
Late Branching/Cheap Branching
In comparison with more recent tools - for example - ClearCase, Plastic SCM, AccuRev, Mercurial, Git - we see a late (cheap) branching policy.
We see that first new versions in a branch are only created when a file is checked in on a branch.
This means that when changes happen on the trunk that you wish to rebase into your branch, no merges for unchanged files occur.
How does TFS behave?
caveats: I note my terminology is not exact when we consider DVCS tools. I recognise Perforce has a round-about way of overlaying views but it's not done without great labour.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
注意：
在 TFS 的“单一开发团队场景 2.0.pdf”文档中分支指南 - Lab.zip 文件中，您将看到分支的创建之后是提交（检查原始分支中的所有文件。
使用的空间已最小化，如协作隔离 页面：
所以对于TFS2008来说它是重分支（带有空间优化）。
在 TFS2010 中，分支是第一类对象，很容易与简单文件夹分开。
Note: the Version Control (ex Branching and Merging) Guide can help here.
In the "Single Dev Team Scenario 2.0.pdf" document of TFS Branching Guide - Lab.zip file, you will see that the creation of a branch is followed by a commit (a checking of all files from the original branch.
The space used is minimized, as described in Isolation for Collaboration page:
So it is heavy branching for TFS2008 (with space optimization).
In TFS2010, branches are first class object and easily separated from simple folders.
我听说 TFS 比后者更接近前者。
I'm told TFS is closer to the former than the latter.
我在 TFS 上工作了 5 年，最近在去年转向了 GIT。
TFS（与 GIT 相比）有两个主要缺点：
1）没有 Rebase 概念。所有分支到分支的交互都是合并。合并破坏了变更集历史记录，并隐藏了提交注释中的所有有用细节。没有精挑细选，没有时间线重建。这导致了无休止的家长巡视，以及认真的研究来确定变更集的历史。
2）毫无根据的合并是一场噩梦。在 TFS 中，如果您在 6 个月前没有碰巧建立分支关系，您将必须进行多次反向/正向集成才能到达目标主干。在 git 中，所有主干始终兼容。
TFS 可以工作，但存在障碍。一些障碍确实影响了我们的交付时间。
到目前为止，我们已经在敏捷团队环境中使用 GIT 做了一些非常先进的事情，并且始终能够在几分钟内找到解决方案来解决每个新的源问题，而不是几小时或几天。晋升层级是抽象的，可以临时交换。开发人员可以“节点到节点”共享变更集，并在推送到公共存储库之前进行协作。
无意冒犯微软，但我就是无法支持一个有这么多开箱即用障碍的工具。
I was on TFS for 5 years and recently switched to GIT in the last year.
There are two major disadvantages to TFS (vs GIT):
1) No Rebase concept. All branch-to-branch interaction is merge. The merge clobbers changeset history, and hides all of the useful details in the commit comments. No Cherry-pick, no timeline rebuild. This leads to endless parent walks, and serious research to determine the history of a changeset.
2) Baseless merge is a nightmare. In TFS, if you did not happen to build the branch relationships 6 months ago, you are going to have to reverse/forward integrate many many times to get to your destination trunk. In git, all trunks are compatible all of the time.
TFS works, but has road-blocks. Some of the road-blocks have really hurt our delivery timelines.
So far, we have been doing some pretty advanced things with GIT in an Agile Team environment and have always been able to meet each new source problem with a solution in minutes not hours or days. Tiers of Promotion are abstract, and can be swapped ad-hoc. Developers can share changesets 'node-to-node', and collaborate on work before pushing to a common repo.
No offense to MS, but I just cannot get behind a tool that has so many obstacles out-of-the-box.
当您在 tfs 2008 中创建分支时，您必须首先签入新的分支文件。一旦您将它们签入，分支的版本控制就会与原始分支分开。
您还可以在分支文件之前跟踪分支文件的历史记录，但需要安装 TFS Follow Branch History Add-in for VS
When you create a branch in tfs 2008 you have to checkin the new branched files first. Once you check them in the versioning of the branch starts separate from the original.
You can also track history of branched files before they have been branched but you need to install TFS Follow Branch History Add-in for VS