Git与Team Foundation Server的对比

Question

我向我的开发团队介绍了Git，除了我之外，每个人都不喜欢它。他们想用Team Foundation Server替换它。我觉得这是一个巨大的倒退，尽管我对TFS并不是很熟悉。有经验的人能否比较一下TFS和Git分支支持？此外，总体上说，TFS有什么优缺点？在使用Git几年后，我会讨厌TFS吗？

- Jacko

---

在这件事上，你会面临一场艰苦的斗争。在Windows平台上，Git远不如svn/hg/tfs成熟，这对于经验丰富的Git用户并不会产生太大影响，但对于新手来说却是一个主要的头疼问题。 - Marcelo Cantos

@Jacko：我在过去几周里一直在评估 Git-for-Windows。虽然相比我大约一年前看到的情况有了显著改进，但它离成为适用于典型的 Windows 开发者的主流工具还有很长的路要走。例如，VS 插件非常糟糕。它只是一堆菜单选项，位于主菜单栏下面，如果选择解决方案而不是项目，则会悄悄地失败。我无法使提交工具索引块和行，这是我使用 git 的主要原因，而使用 git gui（从可用性的角度来看，完全是一个灾难）也非常麻烦。 - Marcelo Cantos

老实说，尽管如此，我还是很难舍弃git。与外界普遍看法相反，我发现git的模型更加强大且更有逻辑性。Mercurial没有任何东西可以与git的索引相匹敌，我也讨厌它的分支方法。Git的标签概念非常优雅，你可以在不同仓库之间移动和同步它们。Mercurial的书签是唯一接近的东西，但对每个人来说都很麻烦。然而，归根结底，考虑到工具的员工和相对成熟度，svn→Mercurial比svn→git更容易成功。 - Marcelo Cantos

是的，Git 在强大和优雅方面确实占据主导地位。但是，并非每个人都准备好使用它。 - Jacko

@JamesReategui: 我个人认为（https://dev59.com/FWXWa4cB1Zd3GeqPQc_z#11362998），在IDE中集成版本控制系统是一种曲折的做法。如果你明天更换主要的IDE，比如从VS转向Eclipse，你是否真的愿意学习一个新的版本控制系统集成？Git在命令行上表现很好 (https://dev59.com/I2035IYBdhLWcg3wErvM#5645910)。学习它，你会发现一个无比强大的版本控制世界。 - eckes

Answer 1

我认为这个说法：

除了我之外，每个人都讨厌它

使得任何进一步讨论都是浪费时间：当你继续使用Git时，如果出现任何问题，他们会责备你。

除此之外，对我而言，Git相对于集中式版本控制系统有两个优点，我最欣赏（正如Rob Sobers所描述的那样）：

• 自动备份整个仓库: 每次有人从中央仓库拉取代码时，他/她会获得完整的更改历史记录。 当一个仓库丢失时：不用担心，从任何工作站上获取即可。
• 离线仓库访问: 当我在家里工作（或在飞机或火车上），我可以看到整个项目的完整历史记录，每个提交，无需启动VPN连接即可像在工作一样：提交，检出，分支等。

但是，正如我所说：我认为当每个人都讨厌Git时，与其试图说服他们，不如了解为什么他们讨厌Git可能更有帮助。

如果他们不想使用它，因为它对他们来说还很陌生，并且不愿意学习新东西：您确定您可以与这些员工成功开展开发工作吗？

真的每个人都讨厌Git吗? 还是受到某些意见领袖的影响？找到这些领袖并问问他们的问题。说服他们，你就会说服团队的其他成员。

如果你不能说服领导者：放弃使用Git，使用TFS。这将使您的生活更轻松。

- eckes

---

没错，Eckes。每当出了问题，他们总是责怪我。而不是因为自己没有学会如何运作。对我来说，Git 是我所经历过的版本控制系统中最接近完美的。 - Jacko

另一方面，TFS 包括缺陷/工作项跟踪、报告等其他功能。因此，仅从版本控制系统的功能来比较 Git 和 TFS 是有点误解 TFS 的意义。 - Richard

@Artefacto 我知道，但这样所有提交的标签都会改变，所有元数据（代码审查讨论等）都会失去关联或需要更新。尽管如此，使用 TFS 一个月让我相信它不在 Git 的版本控制系统之列。Git 使得开发人员可以以一种必须经历才能理解的方式更加高效地生产。分支作为草稿板的比喻非常强大。 - Dan Solovay

@Richard，我认为这是TFS的一个缺点：一旦你使用它，就必须完全使用它。它的各项功能都表现平庸，并且不能让你自由选择。有很多更好的工具可用于追踪工作项、报告和项目管理。 - Ben Collins

TFS中的“shelves”似乎相当于git中的“stash”。虽然它们对于小的更改很有用，但对于超过3天的工作以及连续的更改等情况几乎无效。 - ANeves

Answer 2

两个系统的关键区别在于TFS是集中式版本控制系统，而Git是分布式版本控制系统。
对于TFS，仓库存储在中央服务器上，开发人员检出工作副本，这是代码在特定时间点的快照。 对于Git，开发人员将整个存储库克隆到其计算机上，包括所有历史记录。
在开发人员计算机上拥有完整的存储库的一个好处是，如果服务器死亡，可以进行冗余备份。另一个好处是，您可以在版本之间来回移动工作副本，而无需与服务器通信，如果服务器关闭或无法访问，则这很有帮助。
对我来说，真正的好处是，您可以将变更集提交到本地存储库，而无需与服务器通信或对团队造成可能不稳定的变更（即，破坏构建）。
例如，如果我正在开发一个大功能，可能需要我一周的时间来编码和测试它。 我不想在周中检入不稳定的代码并破坏构建，但如果我接近这一周的结束，并且意外破坏了整个工作副本怎么办？ 如果我一直没有提交，我有失去我的工作的风险。 那不是有效的版本控制，而且TFS容易受到这种影响。
使用DVCS，我可以随时提交而不必担心破坏构建，因为我正在提交我的更改本地。 在TFS和其他集中式系统中，没有本地检入的概念。
我甚至还没有涉及分支和合并在DVCS中有多好，但您可以在SO或通过Google找到大量解释。 我可以告诉你，从经验上讲，TFS中的分支和合并不是很好。
如果您的组织对TFS的论点是它在Windows上的工作效果比Git要好，我建议使用Mercurial，因为它在Windows上工作得很好-与Windows Explorer（TortoiseHg）和Visual Studio（VisualHg）集成。

- Rob Sobers

---

如果你考虑使用Mercurial，Joel Spolsky有一个优秀的教程网站可以为团队提供培训：http://hginit.com/。 - Martin Owen

值得一提的是，Git 完全可以模拟一个集中式系统，并且通常会为所有用户设立一个主 Git 服务器，但并非必须以这种方式操作。 - Tim Abell

如果你正在开发一个可能会影响其他功能的代码模块，那么你可以在 TFS 创建一个分支来进行开发，这样就不会影响到主代码库。虽然这个分支是存储在一个中央服务器上的，但这并不影响使用。实际上，在两种方法中你都能有效地完成同样的操作，区别在于你使用哪个集成开发环境（IDE）以及版本控制系统与其的集成程度。 - William

如果你正在开发一个可能会中断团队的重要功能，建议使用一个特性分支，等准备好后再合并到开发分支中。 - Mike Cheel

这是一个很棒的评论。除了使用分支的方法之外，你还可以每天创建一个代码“货架”，并在最终提交功能时将它们删除。 - RPDeshaies

Answer 3

人们需要放下武器，远离边缘，并且冷静思考一分钟。事实证明，分布式版本控制系统（DVCS）具有客观、具体和不可否认的优势，这将对团队的生产力产生巨大影响。

这一切归结于分支和合并。

在DVCS之前，指导原则是“祈求上帝不要让你进入分支和合并，但如果必须进入，请让它变得非常简单。”

现在，随着DVCS的发展，分支（和合并）得到了很大改进，新的指导原则是，“随时做分支，它将为您带来很多好处，不会给您带来任何问题。”

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

问题是，为了让人们理解我刚才说的话并相信它是真实的，他们首先必须投资一点学习曲线。他们不需要学习Git或任何其他DVCS本身...他们只需要学习Git如何进行分支和合并。读一些文章和博客文章，慢慢地阅读并逐步理解，这可能需要两三天。

但是一旦你理解了，你就不会考虑选择非DVCS了。因为确实存在着明显、客观、具体的DVCS优势，而最大的优势在于分支和合并领域。

- Charlie Flowers

---

谢谢，查理。我知道这点，你也知道，但是很难让那些说“将源代码控制与Visual Studio集成是我最关心的功能”的人明白。 - Jacko

我知道。我和一个朋友打比方说——想象一下你需要一个严肃的关系型数据库。你评估了 SQL Server、Oracle 和 MS Access。最后你选择了 Access，因为它有最漂亮的 GUI，尽管它不能很好地扩展，也不能很好地强制实施引用完整性等。分支和合并是版本控制系统的核心功能。其他功能只是附带的花哨装饰。但是人们基于这些花哨的装饰做出了选择。 - Charlie Flowers

虽然我倾向于同意你的说法，但我不明白为什么Git的分支和合并之所以"更好"，只是因为它是一个"分布式"系统。我不确定作为DVCS是否与它的合并能力有任何关系。我很想知道为什么在分布式系统中合并更容易。根据我的经验，主要是Git和Svn，SVN中的合并很糟糕，不是因为它是集中式VCS，而是因为它没有像GIT一样正确跟踪分支之间的修订版本。 - CodingWithSpike

@rally25rs -- 我大部分都同意。没有理由说一个版本控制系统不能同时擅长合并。只是目前（我所知道的）还没有这样的系统。但是，我不同意的部分是“纯粹通过编写更好的合并程序来解决冲突”。秘诀不在于更好、更智能的合并程序，而在于采取一种基本不同的方法来存储仓库中的信息和组织它。主要是将提交作为内部状态的基础。提交不仅仅是一个很酷的插件......它们是实现功能的基础。 - Charlie Flowers

完全同意@rally25rs所言，提交是工作的原子单位。大多数集中式系统不仅没有以这种方式组织数据，还会阻碍开发人员为实现良好的分支和合并工作而进行的即时性工作。分布式系统鼓励我所谓的“相应”的提交（包含相关工作的自包含小提交和良好的描述），而中心化系统则鼓励我所谓的“差异炸弹”，即你躲在洞里直到准备好后才将数天（或数周）的工作投入系统中。你猜哪种提交方式更容易合并？ - Ben Collins

Answer 4

翻译: @Rob，TFS有一种叫做“Shelving”的功能，它解决了您对提交正在进行的工作，而不影响正式构建的担忧。我知道您认为中央版本控制是一种阻碍，但就TFS而言，将代码检入架子上可以被视为一种优势，因为这样中央服务器就有了您正在进行的工作副本，在您的本地机器崩溃、丢失/被盗或需要快速切换方向的罕见情况下。我的观点是，在这个领域应该给予TFS适当的赞扬。此外，TFS2010中的分支和合并比以前的版本有所改进，在您说“...从经验来看，TFS中的分支和合并不好。”时，不清楚您指的是哪个版本。免责声明：我是TFS2010的普通用户。

编辑于Dec-5-2011：对于OP（原帖发布者），TFS让我困扰的一件事是，当您不在处理本地文件时，它坚持将所有本地文件设置为“只读”。如果您想进行更改，流程是您必须“签出”该文件，这只是清除了文件上的只读属性，以便TFS知道要关注它。这是一个不方便的工作流程。我希望它能自动检测到我是否已经做出了更改，并且根本不用担心/干扰文件属性。这样，我可以使用Visual Studio、Notepad或任何我喜欢的工具修改文件。版本控制系统在这方面应尽可能透明。有一个Windows Explorer扩展程序（TFS PowerTools），它允许您在Windows Explorer中处理文件，但并没有简化工作流程。

- Lee Grissom

---

这回答了问题，即使你有声望，也不应该是评论。 - SingleNegationElimination

FYI - 如果你使用本地工作区（现在是默认设置），TFS "11" 不再需要只读位。它会智能地从任何应用程序中发现哪些文件已更改。关于这些改进，Brian Harry 在这里提供了更多信息：http://blogs.msdn.com/b/bharry/archive/2011/08/02/version-control-model-enhancements-in-tfs-11.aspx - Ed Blankenship

@EdBlankenship，非常感谢您提供的博客链接。看到只读位无聊的问题正在得到解决，以便更轻松地使用下一个版本的TFS，这是一个好消息。 - Lee Grissom

与 Git 中提交到一个分支的方式相反，储存代码片段不易理解和管理。你不知道每个代码片段是何时被储存的，而且在合并代码时经常出现问题（如果自那时起进行了修改，则往往会丢失）。与储存代码片段相比，Git 分支更为强大和易于理解。储存代码片段适用于从未尝试过其他方法的开发人员... - Philippe

这种“检出”文件的工作流程让人想起了Visual SourceSafe，因为这是常见的工作方式；文件从SourceSafe中检索并存储为只读文件。检出一个文件或一组文件可以标记为独占，这意味着其他人可以看到另一个开发人员正在处理的文件集，以避免在禁用分支时需要合并（可能是由于VSS中的某些问题）。 - Brett Rigby

Answer 5

除了已经讨论的所有内容(

https://dev59.com/6W855IYBdhLWcg3wUScW#4416666

https://dev59.com/6W855IYBdhLWcg3wUScW#4894099

https://dev59.com/6W855IYBdhLWcg3wUScW#4415234

), 虽然正确，但TFS并不只是版本控制系统(VCS)。TFS提供的一个主要功能是本地集成的缺陷跟踪功能。更改集与问题相关联，并且可以进行跟踪。支持各种签入策略，以及与Windows域的集成，这是运行TFS的人所需要的。紧密集成的Visual Studio GUI是另一个卖点，它吸引了那些不太平均喜欢用鼠标点击的开发者及其经理。

因此，将Git与TFS进行比较并不是一个适当的问题。正确的问题应该是将Git与TFS的VCS功能进行比较。在这方面，Git胜过TFS。但是，任何严肃的团队都需要其他工具，而这就是TFS提供一站式服务的地方。

- Sherlock

---

您可以在任何敏捷工具应用程序中获得与TFS提供的相同工具。比如Rally等等。 - PositiveGuy

虽然我同意TFS有更广泛的目标，但我会重新表述为“它试图提供一个一站式目的地”，但它在它试图解决的任何任务中都不够好（至少不是最佳选择）；所以它就像一把钝的瑞士军刀。 - slashCoder

@PositiveGuy，如果你不努力工作和配置，是无法得到它的。TFS只需一个点击即可提供整个功能。例如，整个生态系统现在可作为云服务提供，无需任何配置。如果我可以获得版本控制、Scrum支持、自动化构建、测试实验室和测试计划管理等所有集成功能，以及与企业LDAP（如AzureAD）自动关联，每月仅需10美元，那么我为什么还要费心自己拼凑呢？ - Craig Brunetti

@slashCoder，任何一套完整的套件怎么可能在每个方面都是最好的呢？它的非最佳性成本真的比自己管理组件集成的成本更高吗？也许对于某些地方来说确实如此，我能理解。但是运行这样的东西纯粹是额外开销。如果你的公司GIT正常运行，但是你的JIRA实例崩溃了，你的Jenkins升级又不成功怎么办？对吧？这就像玩杂耍一样。还要着火。半盲目的。 :) :) - Craig Brunetti

如果你的公司GIT运行正常，但是JIRA实例崩溃了，而你的Jenkins升级也不成功，会发生什么呢？对吧？这就像是在玩杂耍。火上浇油。半眼瞎。那么你的意思是单点故障比多个应用程序分别运行更可靠吗？ :-) - atb00ker

Answer 6

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

有一些这样的桥接器（在GitHub上）。我在上一个地方与另一位开发人员一起使用了其中一个，并取得了一些成功。请参见： https://github.com/spraints/git-tfs https://github.com/git-tfs/git-tfs

- bytedev

---

微软现在提供了与 Git 代码库和 TFS 的直接集成：http://blogs.msdn.com/b/bharry/archive/2012/08/13/announcing-git-integration-with-tfs.aspx - Ed Blankenship

@EdBlankenship，你可能想要将你的评论转换成答案。它似乎是OP的一个很好的解决方案。我会投票支持它的 :) - Lee Grissom

除非您使用的是Windows以外的平台，否则您应该优先选择git-tfs！ git-tf远不如git-tfs好用...而且其哲学是面向TFS的，而git-tfs更加面向git（这正是我们想要的！） - Philippe

Answer 7

经过一番权衡利弊后，我所涉及的公司决定采用TFS。这并不是因为GIT不是一个好的版本控制系统，而是因为TFS提供了完全集成的ALM解决方案。如果仅仅考虑版本控制功能，选择可能会是GIT。然而，普通开发人员要学习GIT的陡峭学习曲线是不容小觑的。

详细解释请参见我的博客文章：TFS作为真正的跨技术平台。

- Pieter Gheysens

---

或许，但 TFS 的每个部分都很糟糕且难以管理（实际上，你需要一个真正的管理员来管理 TFS）。Git>TFS（版本控制），Jenkins>TFS（持续集成），nunit 或 xunit > mstest，IceScrum 或 ... > TFS（项目管理）。TFS 在一开始是一个好主意，直到你使用它！！！ - Philippe

为什么需要TFS呢？只需获取一个好的敏捷应用程序，然后使用Git或Subversion即可上手。TFS会通过困扰你的问题来阻碍你的进展。 - PositiveGuy

更新：TFS 2013（服务器）[和VS12-13]现在支持Git进行版本控制。因此，您可以兼顾两者的优点。 - DarcyThomas

当然，拥有完全集成的ALM是很好的。但不应以牺牲灵活性为代价。在我看来，ALM应该尽可能地采用“最佳技术”构建，或者至少具有集成最佳技术的灵活性，因为它们随着时间的推移可能会发生变化。选择TFS基本上是在立下一个标志，表示“微软将在我的ALM的所有方面获胜”，这是愚蠢的。例如，我使用过Git w/ Jira，这使我能够根据提交消息更新/关闭问题。根据我的经验（也有很多关于TFS），这是一种极其优秀的工作流程。 - Scott Silvi

侧边栏 - 即使与TFS / Git集成，您基本上也在说“让我们将VCS外包给Git，同时保留我们的问题跟踪” - 从根本上讲与使用任何其他问题跟踪软件的Git没有什么不同。因此，鉴于Microsoft对灵活性的努力（我为此鼓掌），我不确定ALM论点是否仍然有效。 - Scott Silvi

陡峭的GIT学习曲线-我认为这很关键。TFS源代码控制简单且更容易学习。 - Colin

Answer 8

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

- Paddy

---

这里说得很好。Git会添加.git文件夹来跟踪所有存储库的详细信息。TFS将至少修改您的.sln（或者是.csproj？）文件，以将远程存储库的位置放入其中。 - CodingWithSpike

我已经忘记了我曾经有多讨厌VSS为你修改文件的方式。 - Paddy