Git vs Team Foundation Server

这两个系统的关键区别在于，TFS是集中式版本控制系统，Git是分布式版本控制系统。

使用TFS，存储库存储在中央服务器上，开发人员签出工作副本，这是代码在特定时间点的快照。使用Git，开发人员将完整存储库复制到他们的机器上，包括所有的历史记录。

在开发人员的机器上拥有完整的存储库的一个好处是，在服务器崩溃时可以提供冗余。另一个好处是，你可以在不同版本之间来回移动你的工作副本，而无需与服务器通信，这在服务器宕机或无法连接时很有帮助。

对我来说，真正的好处是你可以提交更改集到你的本地存储库，而无需与服务器交谈或对你的团队造成潜在的不稳定更改(即破坏构建)。

例如，如果我正在开发一个大型功能，我可能需要一周的时间来编码和测试。我不想在周中签入不稳定的代码并破坏构建，但是如果我在接近周末时意外地占用了整个工作副本，会发生什么情况呢?如果我一直没有做出承诺，我就有失去工作的风险。这不是有效的版本控制，TFS很容易受此影响。

使用DVCS，我可以不断地提交而不用担心破坏构建，因为我提交的更改是在本地。在TFS和其他集中式系统中，没有本地签入的概念。

我甚至还没有讨论DVCS中的分支和合并有多好，但是你可以在SO或谷歌上找到大量的解释。根据经验，我可以告诉您在TFS中进行分支和合并并不好。

如果你的组织中关于TFS的争论是它在Windows上比Git更好，我建议在Windows上工作得很好的Mercurial——它集成了Windows资源管理器(TortoiseHg)和Visual Studio (VisualHg)。

我想是声明

每个人都讨厌它，除了我

这会浪费进一步的讨论:当你继续使用Git时，如果出现任何问题，他们会责怪你。

除此之外，对我来说，Git比集中式VCS有两个优势，这是我最欣赏的(部分由罗伯·索伯斯描述):

• 整个回购自动备份:每次有人从中央回购，他/她得到一个完整的历史变化。当一个回购丢失时:别担心，在每个工作站都带上一个。
• 离线回购访问:当我在家(或在飞机或火车上)工作时，我可以看到项目的完整历史，每一个签入，而不需要启动我的VPN连接来工作，并且可以像我在工作中是一样工作:签入，签出，分支，任何东西。

但正如我所说:我认为您正在打一场失败的战斗:当每个人都讨厌Git时，就不要使用Git。它可以帮助你更多地了解为什么他们讨厌Git，而不是试图说服他们。

如果他们只是因为这对他们来说是新事物而不想要它，并且不愿意学习新内容，那么你确定你能与这些员工一起成功开发游戏吗?

真的每个人都讨厌Git吗?还是他们受到了一些意见领袖的影响?找到领导，问他们问题出在哪里。说服他们，你就能说服团队的其他人。

如果你不能说服领导者:忘记使用Git，使用TFS。会让你的生活更轻松。

原始: @Rob, TFS有一个叫做“搁置”的东西，它可以在不影响正式构建的情况下解决你对提交在制品的担忧。我知道你认为中央版本控制是一个障碍，但相对于TFS，将你的代码签入货架可以被视为一个优势b/c，然后在你的本地机器崩溃或丢失/被盗或你需要快速切换的情况下，中央服务器有一个正在进行的工作的副本。我的观点是，TFS在这方面应该得到适当的赞扬。另外，TFS2010中的分支和合并比以前的版本有所改进，当你说“…”时，并不清楚你指的是哪个版本。根据经验，在TFS中进行分支和合并是不好的。”免责声明:我是ttfs2010的中度用户。

编辑12月- 5 - 2011:对于OP, TFS让我困扰的一件事是，当你不处理它们时，它坚持将所有本地文件设置为“只读”。如果您想要进行更改，流程是必须“签出”文件，这只是清除文件上的readonly属性，以便TFS知道如何监视它。这是一个不方便的工作流程。我更喜欢它的工作方式是，它只是自动检测，如果我做了更改，不担心/打扰文件属性在所有。这样，我就可以在Visual Studio或记事本中修改文件，或者使用任何我喜欢的工具。在这方面，版本控制系统应该尽可能地透明。有一个Windows资源管理器扩展(TFS PowerTools)，允许你在Windows资源管理器中处理你的文件，但这并没有简化工作流程。

人们需要放下枪，离开窗台，并认为一分钟。事实证明，DVCS有客观的、具体的、不可否认的优势，这将对团队的生产力产生巨大的影响。

这一切都归结为分支和合并。

在DVCS之前，指导原则是“向上帝祈祷，你不必涉足分支和合并。如果你这样做了，至少求他让它变得非常非常简单。”

现在，有了DVCS，分支(和合并)得到了很大的改进，指导原则是:“立即完成。”它会给你带来很多好处，而且不会给你带来任何问题。”

这对于任何团队来说都是一个巨大的生产力助推器。

问题是，为了让人们理解我刚才说的，并相信这是真的，他们必须首先投入一点学习曲线。他们不需要学习Git或任何其他DVCS本身……他们只需要学习Git如何进行分支和合并。一遍又一遍地阅读一些文章和博客文章，慢慢来，直到你看到为止。那可能要花2到3天的时间。

但一旦你看到这一点，你甚至不会考虑选择非dvcs。因为DVCS确实有明确、客观、具体的优势，最大的优势在于分支和合并。

对我来说，主要的区别是TFS将添加到您的解决方案中的所有辅助文件(.vssscc)来“支持”TFS -我们最近遇到了这些文件最终映射到错误的分支的问题，这导致了一些有趣的调试…

最重要的是(

https://stackoverflow.com/a/4416666/172109 < a href = " https://stackoverflow.com/a/4416666/172109 " > < / >

https://stackoverflow.com/a/4894099/172109 < a href = " https://stackoverflow.com/a/4894099/172109 " > < / >

https://stackoverflow.com/a/4415234/172109 < a href = " https://stackoverflow.com/a/4415234/172109 " > < / >

因此，比较Git和TFS并不是一个合适的问题。正确的，尽管不切实际，问题是比较Git和TFS的VCS功能。在这一点上，Git将TFS踢出了水面。然而，任何严肃的团队都需要其他工具，这就是TFS提供的一站式目标。

Git的整个分布式功能真的非常棒。它提供了shelsets(在当前产品中)没有的一些特性，例如本地回滚和提交选项(例如Eclipse的本地历史特性)。您可以使用开发人员分支来缓解这种情况，但老实说，许多开发人员一点也不喜欢分支和合并。我经常被要求在TFS中打开旧式的“独占签出”功能(并且每次都拒绝它)。

我认为许多大型企业都很害怕允许开发人员将整个历史带到本地工作区并随身携带(例如给新雇主)……偷一张快照是不好的，但拿走整段历史就更麻烦了。(不是说你不能从TFS获得完整的历史的你想要它)…

上面提到，这是一种很好的备份方式，这对于开源来说也是很好的，因为原来的维护者可能会停止关心并删除他的版本，但对于企业计划来说，这对于许多企业来说还是不够，因为没有明确的责任分配来保存备份。而且，如果主“项目”以某种方式消失了，就很难弄清楚该使用哪个版本。它倾向于指定一个存储库作为主导/中心。

我最喜欢Git的是Push/Pull选项，在这里你可以轻松地为项目贡献代码，而不需要拥有提交权限。我猜您可以在TFS中使用非常有限的用户和搁置集来模拟这一点，但它没有Git选项那么强大。跨团队项目的分支可能也可以，但从管理的角度来看，这对许多组织来说并不可行，因为添加团队项目会增加大量的管理开销。

我还想在非源代码控制领域补充一些内容。工作项跟踪、报告和构建自动化(包括实验室管理)等特性极大地受益于中央领先的存储库。当您使用纯分布式模型时，这将变得更加困难，除非您使其中一个节点领先(从而返回到较少分布式的模型)。

随着TFS Basic与TFS 11一起推出，在TFS 12+时代，可以将本地TFS Basic同步到中央TFS的分布式TFS可能已经不远了。我将把给下面的用户投票!

在对利弊进行了一番调查后，我所在的公司也决定采用TFS。不是因为GIT不是一个好的版本控制系统，而是最重要的是对于TFS交付的完全集成的ALM解决方案。如果版本控制特性很重要，那么选择GIT可能是最好的。然而，对于普通开发人员来说，陡峭的GIT学习曲线不可低估。

详见我的博客文章TFS是一个真正的跨技术平台。

如果您的团队使用TFS，而您想使用Git，那么您可能需要考虑“Git到TFS”的桥接。从本质上讲，您每天都在计算机上使用Git工作，然后当您想要将更改推送到TFS服务器时，您可以将它们推送到TFS服务器。

有一些(在github上)。我在上一个地方(和另一个开发人员一起)使用了一个，并取得了一些成功。看到的:

https://github.com/spraints/git-tfs < a href = " https://github.com/spraints/git-tfs " > < / >

https://github.com/git-tfs/git-tfs < a href = " https://github.com/git-tfs/git-tfs " > < / >