Git vs Team Foundation Server [关闭]

我向开发团队介绍了Git，除我之外，每个人都讨厌它。他们希望将其替换为Team Foundation Server。尽管我对TFS不太熟悉，但我觉得这是一个巨大的退步。有经验的人可以将TFS的分支支持与Git分支进行比较吗？另外，总体而言，TFS的优缺点是什么？使用Git几年后我会讨厌它吗？

我认为，声明

每个人都讨厌它，除了我

使得任何进一步的讨论都变得浪费：当您继续使用Git时，如果出现任何问题，他们会责怪您。

除此之外，对于我来说，Git与我最欣赏的集中式VCS相比有两个优点（如Rob Sobers所描述的那样）：

• 整个存储库的自动备份：每当有人从中央存储库中提取信息时，他/她都会获得更改的完整历史记录。当一个仓库丢失时：不要担心，请在每个工作站上使用其中之一。
• 离线回购访问：当我在家里工作（或者在飞机或火车上），我可以看到这个项目，每一个签入的全部历史，不启动工作我的VPN连接，并能正常工作像我是在工作中：签到，签出，分支等任何内容。

但是正如我所说：我认为您正在与一场失败的战斗搏斗：当所有人都讨厌Git时，请不要使用Git。它可以帮助您更多地了解为什么他们讨厌Git，而不是试图说服他们。

如果他们只是不想要它，因为这对他们来说是新事物，并且不愿意学习新知识：您确定要与该员工一起成功发展吗？

真的每个人都讨厌Git还是受到某些意见领袖的影响？找到领导者，然后问他们有什么问题。说服他们，您将说服团队的其他成员。

如果您不能说服领导者：忘记使用Git，请使用TFS。将使您的生活更轻松。

这两个系统之间的主要区别在于TFS是集中式版本控制系统，而Git是分布式版本控制系统。

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

在开发人员的计算机上拥有完整存储库的好处之一是可以在服务器死机时实现冗余。另一个不错的好处是，您可以在修订版本之间来回移动工作副本，而无需与服务器对话，这在服务器关闭或无法访问时很有用。

对我来说，真正的好处是您可以承诺更改集到本地存储库，而无需与服务器对话或对团队造成潜在的不稳定更改（即，破坏构建）。

例如，如果我正在开发一项重大功能，则可能需要一周的时间来进行编码和完整测试。我不想在周中检入不稳定的代码并破坏构建，但是如果我快要在周末结束并且不小心弄乱了整个工作副本，会发生什么情况？如果我一直都没有做出承诺，那我就有失去工作的风险。这不是有效的版本控制，因此TFS容易受到此影响。

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

我什至没有研究DVCS中更好的分支和合并方式，但是您可以在SO上或通过Google找到很多解释。我可以从经验中告诉您，在TFS中进行分支和合并是不好的。

如果组织中关于TFS的观点是它在Windows上比Git更好，那么我建议使用Mercurial，它在Windows上效果很好-与Windows资源管理器（TortoiseHg）和Visual Studio（VisualHg）集成在一起。

人们需要放下枪，远离窗台，然后思考一分钟。事实证明，DVCS具有客观，具体和不可否认的优势，这将极大地提高团队的生产力。

全部归结为分支和合并。

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

现在，通过DVCS，分支（并合并）得到了很大的改善，指导原则是：“轻而易举地做到这一点。它将为您带来很多好处，而不会给您带来任何问题。”

对于任何团队来说，这都是巨大的生产力提升。

问题是，要使人们理解我刚才说的话并确信这是事实，他们必须首先投资一点学习曲线。他们不必学习Git或任何其他DVCS本身……他们只需要学习Git如何进行分支和合并即可。阅读并重新阅读一些文章和博客文章，然后慢慢阅读，直到发现为止。这可能需要2到3天的大部分时间。

但是，一旦看到这一点，您甚至都不会考虑选择非DVCS。因为DVCS确实具有明显，客观，具体的优势，所以最大的成功在于分支和合并领域。

原文：@ Rob，TFS有一个称为“ 货架 ”的东西 ”，解决你关于commiting工作正在进行又不影响官方的构建问题。我意识到您认为中央版本控制是一个障碍，但是就TFS而言，将您的代码检查入架可以看作是强项，那么在极少数情况下，中央服务器会复制您的在制品您的本地计算机崩溃或丢失/被盗，或者您需要快速切换齿轮。我的观点是，在这方面应该给TFS适当的赞美。另外，TFS2010中的分支和合并已从以前的版本中得到了改进，当您说“ ...根据经验，TFS中的分支和合并不好时”，您所指的是哪个版本尚不清楚。免责声明：我是TFS2010的中度用户。

编辑Dec-5-2011：对于OP，令我烦恼的是TFS，它坚持要在不使用本地文件时将所有本地文件设置为“只读”。如果要进行更改，流程是必须“检出”该文件，该操作仅清除文件上的readonly属性，以便TFS知道要注意它。这是一个不方便的工作流程。我希望它起作用的方式是，它会自动检测我是否进行了更改，并且完全不用担心文件属性。这样，我可以在Visual Studio或记事本中，或使用我喜欢的任何工具来修改文件。在这方面，版本控制系统应尽可能透明。有一个Windows资源管理器扩展（TFS PowerTools），这样您就可以在Windows资源管理器中处理文件，但是并不能大大简化工作流程。

最重要的是（

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

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

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

），这是正确的，TFS不仅仅是VCS。TFS提供的一项主要功能是本机集成的错误跟踪功能。变更集与问题相关，可以进行跟踪。支持各种签入策略以及与Windows域集成，这是运行TFS的人们所拥有的。与Visual Studio紧密集成的GUI是另一个卖点，它吸引的鼠标和单击开发人员及其经理的吸引力低于平均水平。

因此，将Git与TFS进行比较并不是一个适当的问题。正确（尽管不切实际）的问题是将Git与TFS的VCS功能进行比较。那时，Git将TFS吹出了水面。但是，任何认真的团队都需要其他工具，这是TFS提供一站式服务的地方。

如果您的团队使用TFS，而您想使用Git，则可能需要考虑“从git到tfs”的桥梁。本质上，您每天在计算机上使用Git进行工作，然后当您要推送更改时将其推送到TFS服务器。

有一对夫妇（在github上）。我在最后一个地方（以及另一个开发人员）使用了一个，但取得了一些成功。看到：

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

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

在利弊之间进行了一些调查之后，我所参与的公司也决定选择TFS。不是因为GIT并不是一个好的版本控制系统，而是最重要的是对于TFS提供的完全集成的ALM解决方案。如果仅版本控制功能很重要，则选择可能是GIT。但是，对于普通开发人员而言，陡峭的GIT学习曲线可能不会被低估。

请参阅我的博客文章TFS中作为一个真正的跨技术平台的详细说明。

Git的整个Distributed东西真的很棒。它提供了Shelvesets在当前产品中没有的一些功能，例如本地回滚和提交选项（例如Eclipse的localhistory功能））。您可以使用开发人员分支来缓解这种情况，但是老实说，许多开发人员不喜欢分支和合并。我被要求过几次频繁地在TFS中打开旧式的“独占结帐”功能（并且每次都拒绝该功能）。

我认为许多大型企业非常害怕允许开发人员将整个历史记录带入本地工作区并随身携带（例如，交给新雇主）...偷快照是不好的，但是要删除整个历史记录更加麻烦。（并不是说您无法从TFS获得想要的完整历史记录）...

提到这是一种很好的备份方式，这又对开源非常有用，因为原始维护者可能会停止关心并删除其版本，但是对于企业计划，由于没有明确的职责分工，这对于许多企业来说还是不够的保留备份。如果主要的“项目”以某种方式消失，将很难确定要使用哪个版本。倾向于任命一个存储库为领导/中央存储库。

我最喜欢Git的是Push / Pull选项，在这里您可以轻松地向项目贡献代码，而无需拥有提交权限。我想您可以在TFS中使用非常有限的用户和架子集来模仿这一点，但是它不如Git选项强大。跨团队项目进行分支也可能会起作用，但是从管理角度来看，对于许多组织来说，这实际上是不可行的，因为添加团队项目会增加很多管理上的开销。

我还要添加非源代码控制区域中提到的内容。中央领先的存储库极大地受益于工作项跟踪，报告和构建自动化（包括实验室管理）等功能。当您使用纯分布式模型时，这些操作将变得更加困难，除非您使节点之一处于领先地位（从而返回到分布较少的模型）。

随TFS 11一起提供的TFS Basic可能并不遥不可及，期望有一个分布式TFS，它使您可以在TFS 12+时代将本地TFS Basic同步到中央TFS。我将在Uservoice中对此投下赞成票！

对我而言，主要区别在于TFS将添加到解决方案（.vssscc）中的所有辅助文件以“支持” TFS-我们最近遇到了这些文件最终映射到错误分支的问题，这导致了一些有趣的调试...