Git vs Team Foundation Server
我把Git介绍给我的开发团队，除了我之外，每个人都讨厌它。 他们想用Team Foundation Serverreplace它。 我觉得这倒退了一大步，尽pipe我对TFS不是很熟悉。 有经验的人可以将TFS上的分支支持与Git分支进行比较吗？ 另外，一般来说，TFS的优点和缺点是什么？ 使用Git几年后我会讨厌它吗？
我认为，声明
除了我，每个人都讨厌它
进一步讨论浪费：当你继续使用Git时，如果出现任何问题，他们会责怪你 。
除此之外，对我来说，Git比我最欣赏的集中式VCS有两个优势（ Rob Sobers部分描述）：
- 整个回购的自动备份：每当有人从中央回购中心撤出时，他/她会得到完整的变更logging。 当一个回购丢失时：不要担心，拿一个出现在每个工作站上的人。
- 离线回购访问：当我在家里（或在飞机或火车上）工作时，我可以看到项目的全部历史logging，每一次签到，不用开启我的VPN连接工作，并可以像我在工作：签入，结帐，分支，任何东西。
但正如我所说：我认为你正在战斗中失败：每个人都讨厌Git，不要使用Git。 它可以帮助你更多地知道他们为什么讨厌Git，而不是试图说服他们。
如果他们根本就不想要，那对他们来说是新鲜的，不愿意学习新的东西：你确定你会和那个员工一起成功发展吗？
真的每个人都讨厌Git，还是受到一些意见领袖的影响？ find领导，问问他们有什么问题。 说服他们，你会说服团队的其他成员。
如果你不能说服领导者：忘记使用Git，拿TFS。 会让你的生活更轻松。
两个系统的主要区别在于TFS是一个集中版本控制系统，而Git是一个分布式版本控制系统。
使用TFS，存储库存储在中央服务器上，开发人员检出工作副本，这是工作副本的特定时间点的快照 。 使用Git，开发人员可以将整个存储库复制到他们的机器上，包括所有的历史logging。
在开发人员的机器上拥有完整存储库的一个好处是在服务器死亡的情况下是冗余的。 另一个好处是，你可以在修改版本之间来回移动你的工作副本，而不必与服务器交谈，如果服务器closures或者只是无法访问，这可能会有帮助。
对我来说，真正的好处是你可以将变更集提交到本地存储库，而不必与服务器通话或对你的团队造成潜在的不稳定变化（即中断构build）。
例如，如果我正在开发一个大function，那么可能需要一个星期的时间才能完成代码和testing。 我不想在周中签入不稳定的代码，并打破构build，但如果我接近本周结束，并且不小心将我的整个工作副本捆绑在一起，会发生什么？ 如果我一直没有作出承诺，我将面临失去工作的风险。 这不是有效的版本控制，而TFS容易受此影响。
有了DVCS，我可以不断地提交而不必担心打破构build，因为我正在本地提交更改。 在TFS和其他集中式系统中，没有本地登记的概念。
我甚至没有进入DVCS的分支和合并，但是你可以在这里find大量的解释或通过谷歌。 我可以从经验告诉你，TFS中的分支和合并不好。
如果你组织中的TFS的参数是在Windows上比Git更好的话，我会build议Mercurial，它在Windows上很好用 – 与Windows资源pipe理器（TortoiseHg）和Visual Studio（VisualHg）集成。
人们需要放下枪，离开窗台， 想一会儿。 事实certificateDVCS具有客观，具体和不可否认的优势，这将使团队的生产力产生巨大的差异。
这一切归结为分支和合并。
在DVCS之前，指导原则是“向上帝祈祷，你不必进行分支和合并，如果你这样做，至less请求他让它变得非常简单。”
现在，在DVCS中，分支（ 合并 ）得到了很大的改善，其指导原则是“戴上帽子，这样会给你带来很多好处，不会给你带来任何问题”。
这对于任何球队来说都是一个巨大的生产力推动者。
问题是，为了让人们明白我刚刚所说的话，并确信这是事实，他们必须首先投资一点点学习曲线。 他们不必学习Git或任何其他DVCS本身…他们只需要了解Git如何分支和合并。 阅读和重新阅读一些文章和博客文章，慢慢来，并通过它，直到你看到它。 这可能需要整整两三天的时间。
但一旦你看到了，你甚至不会考虑select一个非DVCS。 因为DVCS确实有明确，客观，具体的优势，而且在分支和合并方面最大的胜利。
原文 ：@Rob，TFS有一个叫做“Shelving”的东西，它解决了你在进行正在进行的工作而不影响官方构build的问题。 我意识到你看到中央版本控制是一个障碍，但就TFS而言，检查你的代码到货架上可以被看作是一个强大的B / C，那么中央服务器有一个在罕见的事件正在进行中的副本您的本地机器崩溃或丢失/被盗或您需要快速切换齿轮。 我的意思是TFS应该在这方面得到适当的赞扬。 而且，TFS2010中的分支和合并已经从之前的版本中得到了改进，当您说“…从经验中分享和合并到TFS中并不好”时，您所指的是什么版本并不清楚。 免责声明：我是TFS2010的中等用户。
编辑12 – 5 – 2011年 ：对于OP来说，困扰我的TFS的一件事是，它坚持设置所有本地文件“只读”，当你不在他们的工作。 如果你想改变，stream程是你必须“检出”文件，这只是清除文件的只读属性，以便TFS知道要留意它。 这是一个不方便的工作stream程。 我更喜欢它的工作方式是，只是自动检测，如果我已经做了一个变化，并不担心/打扰文件属性。 这样，我可以在Visual Studio或记事本中修改文件，也可以用我喜欢的任何工具修改文件。 版本控制系统在这方面应该尽可能的透明。 有一个Windows资源pipe理器扩展（ TFS PowerTools ），允许您在Windows资源pipe理器中使用您的文件，但这并不能简化工作stream程。
除了所说的一切之外（
https://stackoverflow.com/a/4416666/172109
），这是正确的，TFS不只是一个VCS。 TFS提供的一个主要function是本地集成的错误跟踪function。 变更集链接到问题，可以跟踪。 支持各种检入策略，以及与Windows域的集成，这是运行TFS的人所拥有的。 与Visual Studio紧密集成的GUI是另一个卖点，它吸引了不到一般的鼠标和点击开发人员和他的经理。
因此，将Git与TFS进行比较并不是一个恰当的问题。 正确但不切实际的问题是将Git与TFS的VCSfunction进行比较。 在那，Git把TFS从水里吹出来。 但是，任何严肃的团队都需要其他工具，而这正是TFS提供一站式目的地的地方。
如果你的团队使用TFS并且你想使用Git，你可能需要考虑一个“git to tfs”的桥梁。 基本上，你每天在你的计算机上使用Git，然后当你想推送你的更改时，把它们推送到TFS服务器。
有一对夫妇（在github上）。 我在最后一个地方（与另一个开发人员一起）使用了一个，取得了一些成功。 看到：
经过一番正反两面的调查，我所涉及的公司也决定去TFS。 不是因为GIT不是一个好的版本控制系统，而是最重要的是TFS提供的完全集成的ALM解决scheme。 如果只有版本控制function很重要，那么select可能是GIT。 常规开发商的GIT学习曲线可能不会被低估。
在我的博客文章TFS中看到一个真正的跨技术平台的详细解释。
Git的整个分布式的东西真的很棒。 它提供了一些Shelveset没有的function（在当前的产品中），比如本地回滚和提交选项（比如Eclipse的localhistoryfunction ）。 你可以使用开发者分支缓解这个问题，但是说实话，很多开发者不喜欢分支和合并。 我被要求在TFS中多次打开旧式的“独家结帐”function（并且每次都拒绝）。
我认为很多大型企业都很害怕让一个开发者把整个历史带入一个本地的工作空间，然后把它带到一个新的雇主手中……窃取快照是不好的，但是把整个历史更麻烦。 （不是说你不能从TFS得到你想要的完整的历史logging ）…
有人提到这是一个很好的备份方式，这对于开源来说又是好事，原来的维护者可能会停下来去关心和删除他的版本，但是对于一个企业来说，由于没有明确的责任分工保持备份。 如果主“项目”以某种方式消失，那么很难确定使用哪个版本。 这往往会指定一个存储库作为领导/中央。
Git最喜欢的是推/拉（Push / Pull）选项，您可以轻松地将代码贡献给项目，而不需要提交权限。 我想你可以在TFS中使用非常有限的用户和shelvesets来模仿这个，但是它没有Git选项那么强大。 在团队项目之间进行分支也可能会起作用，但从pipe理angular度来看，对于许多组织来说这并不是真的可行，因为添加团队项目会增加很多pipe理开销。
我也想补充一下在非源代码控制领域提到的东西。 诸如工作项目跟踪，报告和构build自动化（包括实验室pipe理）等function可从中央领先的存储库中受益匪浅。 当你使用一个纯粹的分布式模型时，这些会变得更加困难，除非你让其中一个节点领先（因此回到一个分布较less的模型）。
随着TFS Basic与TFS 11一起推出，预计分布式TFS可以让您在TFS 12+时代将本地TFS基本同步到中央TFS。 我将把我的投票，在用户发言 ！
对我来说，主要区别在于TFS将添加到您的解决scheme（.vssscc）以支持TFS的所有附属文件 – 我们已经将这些文件的最近问题映射到错误的分支，从而导致一些有趣的debugging…
