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

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

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

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

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

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

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

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

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

最重要的是(

https://stackoverflow.com/a/4416666/172109 https://stackoverflow.com/a/4894099/172109 https://stackoverflow.com/a/4415234/172109

)， 这是正确的，TFS不仅仅是一个风险投资。TFS提供的一个主要特性是本机集成的错误跟踪功能。变更集与问题相关联，并且可以跟踪。支持各种签入策略，以及与Windows域的集成，这是运行TFS的人所拥有的。与Visual Studio紧密集成的GUI是另一个卖点，这吸引了鼠标和点击较少的开发人员及其经理。

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

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

关于TFS作为一个真正的跨技术平台的详细解释，请参阅我的博客文章。

我想是声明

每个人都讨厌它，除了我

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

除此之外，对我来说，Git比集中式VCS有两个优势，这是我最欣赏的(Rob Sobers部分描述过):

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

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

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

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

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

Original: @Rob, TFS has something called "Shelving" that addresses your concern about commiting work-in-progress without it affecting the official build. I realize you see central version control as a hindrance, but with respect to TFS, checking your code into the shelf can be viewed as a strength b/c then the central server has a copy of your work-in-progress in the rare event your local machine crashes or is lost/stolen or you need to switch gears quickly. My point is that TFS should be given proper praise in this area. Also, branching and merging in TFS2010 has been improved from prior versions, and it isn't clear what version you are referring to when you say "... from experience that branching and merging in TFS is not good." Disclaimer: I'm a moderate user of TFS2010.

Edit Dec-5-2011: To the OP, one thing that bothers me about TFS is that it insists on setting all your local files to "read-only" when you're not working on them. If you want to make a change, the flow is that you must "check-out" the file, which just clears the readonly attribute on the file so that TFS knows to keep an eye on it. That's an inconvenient workflow. The way I would prefer it to work is that is just automatically detects if I've made a change and doesn't worry/bother with the file attributes at all. That way, I can modify the file either in Visual Studio, or Notepad, or with whatever tool I please. The version control system should be as transparent as possible in this regard. There is a Windows Explorer Extension (TFS PowerTools) that allows you to work with your files in Windows Explorer, but that doesn't simplify the workflow very much.