我向我的开发团队介绍了Git，除了我，每个人都讨厌它。他们想要替换 它与Team Foundation Server一起使用。尽管我对TFS不是很熟悉，但我觉得这是一个倒退的巨大一步。有经验的人可以比较TFS上的分支支持和Git分支吗？另外，总的来说，TFS的优点和缺点是什么？我以后会恨它 使用Git几年？
答案 0 :(得分：251)
我认为，声明
每个人都讨厌除了我
进一步讨论浪费：当你继续使用Git时，如果出现任何问题，他们会责怪你。
除此之外，对我而言，Git比我最欣赏的集中式VCS有两个优势（部分由Rob Sobers描述）：
但正如我所说：我认为你正在打败一场失败的战斗：当每个人都讨厌Git时，不要使用Git。它可以帮助你更多地了解为什么他们讨厌Git 而不是试图让他们说服他们。
如果他们根本不想要它，因为它对他们来说是新手并且不愿意学习新东西：你确定你会与那些员工一起成功开发吗？
真的每个人都讨厌Git，还是受到一些意见领袖的影响？找到领导者并问他们问题是什么。说服他们，你会说服团队的其他成员。
如果你无法说服领导者：忘记使用Git，那就拿TFS吧。会让你的生活更轻松。
答案 1 :(得分：91)
两个系统的主要区别在于TFS是一个集中式版本控制系统，而Git是一个分布式版本控制系统。
使用TFS，存储库存储在中央服务器上，开发人员签出工作副本，这是特定时间点代码的快照。使用Git，开发人员将整个存储库克隆到他们的计算机上，包括所有历史记录。
在开发人员的计算机上拥有完整存储库的一个好处是服务器死机时的冗余。另一个好处是你可以在不修改服务器的情况下在修订版之间来回移动工作副本，这在服务器关闭或无法访问时会很有帮助。
对我而言，真正的好处是，您可以提交更改集到您的本地存储库，而无需与服务器通信或对您的团队造成潜在的不稳定更改（即，破坏构建）。
例如，如果我正在开发一个大功能，可能需要一个星期的时间才能完全编码和测试它。我不想在周中签入不稳定的代码并打破构建，但是如果我接近本周结束并且我不小心将我的整个工作副本丢了，会发生什么？如果我一直没有承诺，我就有失去工作的风险。这不是有效的版本控制，TFS很容易受此影响。
使用DVCS，我可以不断提交而不用担心破坏构建，因为我正在进行我的更改本地。在TFS和其他集中式系统中，没有本地登记的概念。
我甚至没有考虑过在DVCS中有多好的分支和合并，但你可以在SO或谷歌上找到大量的解释。我可以从经验告诉你，TFS中的分支和合并并不好。
如果组织中TFS的论点是它在Windows上比Git更好，我会建议在Windows上运行良好的Mercurial - 与Windows资源管理器（TortoiseHg）和Visual Studio（VisualHg）集成。
答案 2 :(得分：86)
人们需要放下枪，离开窗台，想想一分钟。事实证明，DVCS具有客观，具体和不可否认的优势，这将为团队的生产力带来巨大的变化。
这一切都归结为分支和合并。
在DVCS之前，指导原则是“向上帝祈祷，你不必进入分支和合并。如果你这样做，至少请求他让它变得非常非常简单。”
现在，使用DVCS，分支（和合并）得到了很大的改善，其指导原则是，“做到这一点。它会给你带来很多好处，而不是引起你的任何问题。“
对于任何团队来说，这都是一个巨大的生产力助推器。
问题是，让人们理解我刚刚说过的话并确信这是真的，他们必须先投入一点学习曲线。他们不需要学习Git或任何其他DVCS本身......他们只需要了解Git如何进行分支和合并。阅读并重新阅读一些文章和博客文章，慢慢来，并通过它直到你看到它。这可能需要2或3整天的大部分时间。
但是一旦你看到了，你甚至不会考虑选择非DVCS。因为DVCS确实有明确，客观，具体的优势，最大的优势在于分支和合并。
答案 3 :(得分：44)
原创：@ Rob，TFS有一个名为“Shelving”的东西，可以解决您在提交正在进行的工作时所关注的问题，而不会影响官方构建。我意识到你看到中央版本控制是一个障碍，但就TFS而言，检查你的代码到架子上可以看作是一个强大的b / c然后中央服务器有一份正常工作的副本在罕见的事件中您的本地机器崩溃或丢失/被盗或您需要快速切换齿轮。我的观点是TFS应该在这方面得到适当的赞扬。此外，TFS2010中的分支和合并已经从以前的版本进行了改进，当您说“......从经验来看，TFS中的分支和合并不好”时，您所指的是什么版本并不清楚。免责声明：我是TFS2010的温和用户。
编辑Dec-5-2011 ：对OP来说，困扰我TFS的一件事是它坚持在你不工作时将所有本地文件设置为“只读”在他们。如果你想进行更改，那么流程就是你必须“检出”文件，这只是清除文件上的readonly属性，以便TFS知道要密切关注它。这是一个不方便的工作流程。我希望它工作的方式是只是自动检测我是否进行了更改，并且根本不担心/烦恼文件属性。这样，我可以在Visual Studio或Notepad中修改文件，或者使用我喜欢的任何工具。在这方面，版本控制系统应尽可能透明。有一个Windows资源管理器扩展（TFS PowerTools），允许您在Windows资源管理器中使用您的文件，但这并不能简化工作流程。
答案 4 :(得分：18)
除了所说的一切之外（
https://stackoverflow.com/a/4416666/172109
），
这是正确的，TFS不仅仅是一个VCS。 TFS提供的一个主要功能是本机集成的错误跟踪功能。变更集与问题相关联，可以跟踪。支持各种签入策略，以及与Windows域集成，这是运行TFS的人所拥有的。与Visual Studio紧密集成的GUI是另一个卖点，它吸引低于平均鼠标并点击开发人员和他的经理。
因此，将Git与TFS进行比较并不是一个值得提出的问题。正确但不切实际的问题是将Git与TFS的VCS功能进行比较。那时，Git将TFS从水中吹走。但是，任何认真的团队都需要其他工具，这就是TFS提供一站式目的地的地方。
答案 5 :(得分：17)
如果您的团队使用TFS并且您想使用Git，您可能需要考虑使用“git to tfs”桥接器。基本上，您每天都在计算机上使用Git工作，然后当您想要推送更改时，将它们推送到TFS服务器。
那里有一对（在github上）。我在最后一个地方（和另一个开发者一起）使用了一个并取得了一些成功。参见：
答案 6 :(得分：15)
经过一番调查，我参与的公司也决定去TFS。不是因为GIT不是一个好的版本控制系统，而是最重要的是TFS提供的完全集成的ALM解决方案。如果只有版本控制功能很重要，那么选择可能就是GIT。然而，对于常规开发人员来说，陡峭的GIT学习曲线可能不会被低估。
请参阅我的博文TFS as a true cross-technology platform中的详细说明。
答案 7 :(得分：14)
Git的整个分布式内容非常棒。它提供了Shelvesets没有（在当前产品中）的一些功能，例如本地回滚和提交选项（例如Eclipse's localhistory feature）。您可以使用开发人员分支来缓解这种情况，但说实话，许多开发人员不喜欢分支和合并一点。我被要求在TFS中频繁打开旧式“独家结账”功能几次（并且每次都拒绝）。
我认为许多大型企业都非常害怕允许开发人员将整个历史记录带入本地工作区并随身携带（例如新员工）...窃取快照很糟糕，但是带走了整个历史更加麻烦。 （不是说你不能get a full history from TFS想要它）......
提到它是一种很好的备份方式，这对于开源来说非常有用，原来的维护者可能会停下来关心并删除他的版本，但是对于企业计划来说，这对于许多企业而言仍然不足，因为没有明确的分配保留备份的责任。如果主要的“项目”以某种方式消失，那么很难确定使用哪个版本。这往往会指定一个存储库作为前导/中心。
我最喜欢Git的是Push / Pull选项，您可以轻松地为项目贡献代码，而无需拥有提交权限。我猜你可以在TFS中使用非常有限的用户和搁置集来模仿这个，但它没有Git选项那么强大。跨团队项目的分支也可能有效，但从管理角度来看，对于许多组织来说这并不可行，因为添加团队项目会增加大量管理开销。
我还想添加非源控件区域中提到的内容。工作项跟踪，报告和构建自动化（包括实验室管理）等功能从中央领先的存储库中受益匪浅。当您使用纯分布式模型时，这些变得更加困难，除非您将其中一个节点引导（因此返回到分布较少的模型）。
随着TFS 11推出TFS 11，预计分布式TFS可能并不遥远，它允许您将本地TFS基本同步到TFS 12+时代的中央TFS。我会把我的vote for that down in the uservoice！
答案 8 :(得分：9)
对我而言，主要区别在于TFS将为您的解决方案添加的所有辅助文件（.vssscc）以“支持”TFS - 我们最近遇到的问题是这些文件最终映射到错误的分支，导致一些有趣的调试...