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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

https://github.com/spraints/git-tfs

https://github.com/git-tfs/git-tfs

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

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

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

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

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

随着TFS Basic与TFS 11一起推出，在TFS 12+时代，可以将本地TFS Basic同步到中央TFS的分布式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.

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