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

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

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

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

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

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

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

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

对我来说，主要的区别是TFS将添加到您的解决方案中的所有辅助文件(.vssscc)来“支持”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作为一个真正的跨技术平台的详细解释，请参阅我的博客文章。

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.