GitHub企业版与Team Foundation Server（TFS）的比较

Question

我所在的公司即将开始一个新项目，这是一个使用C++和C#进行软件开发的项目，有三个地点的6-8名开发人员参与。

旧项目使用SVN和自定义问题跟踪器，但计划切换到TFS。对于这个新项目，我想说服管理层使用GitHub Enterprise而不是TFS。虽然我没有太多关于TFS的经验，但我使用过git，并且有一些GitHub的经验。

具体而言，我要问的是完整的体验，即版本控制、问题/错误跟踪和Wiki的集成。这里有一些相关的问题，但它们只关注版本控制方面。所以：

• GitHub Enterprise相比TFS的主要优势是什么？
• TFS提供了哪些GitHub Enterprise无法复制的好处？
• 这两种解决方案中哪一种更好地支持持续集成？

所有开发都将在使用Visual Studio（2010，可能是2012）的Windows机器上进行。

- Wilbert

---

Team Foundation Service (http://tfs.visualstudio.com) 和 Team Foundation Server 2013 现在允许您在 TFS 实例内托管多个 Git 存储库和传统版本控制存储库（如果选择）。根据您的方向选择托管或本地版本。现在将 Git 纳入 TFS，使您可以享受 TFS 的所有其他好处，但具有企业级真正的 Git 实现。在此处查看更多详细信息：http://blogs.msdn.com/b/bharry/archive/2013/06/19/enterprise-grade-git.aspx - Ed Blankenship

@jlo-gmail 我们已经使用 GitHub:Enterprise 四年了。虽然我同意 Git 学习曲线陡峭，但我们现在拥有了一个流程和工作流，比 TFS 更高效。个人分支+CI 构建、便宜的分支等等——我无法想象回到像 TFS 或 Subversion 这样的东西。而且我们的开发人员也喜欢 Git，甚至希望我们将所有遗留项目迁移到 GitHub（即使他们每年只需要处理这些项目几天）。所以我只能说……攀登学习曲线，你也会看到好处…… - Wilbert

在某个时刻，你必须将你的“个人中心”合并到主分支中以发布一个产品。此时，你需要决定是否信任自动合并过程。我的问题是看似无止境的 Git 学习曲线。我花了很多时间去理解 Git 的特殊之处，已经数不清了。如果过去的本地提交与主线不兼容会发生什么呢？ - jlo-gmail

@jlo-gmail，很抱歉，但是你的话恰恰表明你还没有掌握学习曲线的顶端......不，你不需要相信自动合并过程。你可以在本地基于主分支进行变基，然后发起拉取请求，CI可以在它接触主分支之前构建和测试你的拉取请求。如果你做得对（因为你可以在推送到你的hub之前在本地修复所有问题），你永远不会遇到过去的本地提交不兼容的情况。 - Wilbert

当我谈到信任合并时，我指的是它如何完美地结合在一起。当然，自动合并、CI和测试可以告诉你是否“可行”，但你仍然需要眼睛来确保你的合并不会破坏以前的更改——而适合并不能解决这个问题。这都是无聊的事情，因为真正的问题是我花费在处理git问题上的时间。目前我不信任我的存储库，这意味着我需要保留它的副本以确保我不会丢失工作——假设我能再次找到它。Git就是我从开源社区所期望的一切... masochistic pain. - jlo-gmail

Answer 1

我不能给您一个完整的答案。但是我们研究了TFS用于Java开发，以下是一些可能对您有用的要点。

• 在使用TFS时，路径+文件名存在长度限制。这似乎更适用于Java，因为C＃中的打包方式不同。
• 锁定：创建文件会在TFS中锁定它（或保留一个“位置”）。当人们不在房间里修复这些文件时，这变得非常恼人。对于分布式团队，我无法想象这该如何工作。
• 使用Java进行CI很混乱。虽然可以工作，但与Jenkings / Hudson / Bamboo / TeamCity相比，我不会将其用于Java。使用C＃可能更有趣，因为TFS允许CI构建的工作流程。因此，某些构建可以升级为自动部署。但我从未在实际生活中使用过它。我只是喜欢这个想法 :)
• TFS中的问题跟踪还可以。也有一些Scrum / Agile计划插件可用
• TFS维基白费力气。但是GitHub维基基于Git，因此人们需要编写标记。这对开发人员来说没问题，但我对我们的团队成员是否来自那个领域有些怀疑。
• 我不知道GitHub是否内置了任何CI？我知道的所有CI服务器都支持Git。
• Git Windows客户端有点奇怪。msysgit客户端存在路径长度限制，cygwin更奇怪（只是因为感觉），但两者都很好用。GitHub有自己的客户端-我不知道它基于什么。

考虑到您的团队是分布式的，我建议使用Git。它将允许更灵活的工作流程。如果网络稳定，TFS肯定也能胜任。如果您以前使用过SVN：作为源代码控制的TFS几乎肯定会惹恼人们。但是，习惯于VisualStudio和MS-Server-Parts的开发人员与之冲突较少。

再次强调：我们尝试（或不得不尝试）使用TFS + Java，在C＃+ Visual Studio中完全不同。集成将更好。但是我的一些要点仍然可能有用 :)

- wemu

---

路径长度限制更多地与Windows API有关，而不是其他任何事情。我同意Java的CI，尽管它一直在改进。 - Ryan Riehle

你可能应该看一下 git 扩展 GUI 客户端供 Windows 使用。它非常简单易用，提供高级功能，如逐行暂存和重置，完全开源且免费。 - Wilbert

Answer 2

我不能对TFS发表评论，因为我的经验很短，并且非常不愉快，所以我不会谈论它。

然而，我经常使用git和github（包括企业版），并且我曾经使用过各种集中式版本控制系统（rcs、cvs、svn、synergy）和分布式版本控制系统（hg、git）。

我认为GIT和TFS的主要区别除了一些辅助功能之外，根本上是TFS是一个集中式系统（像rcs、cvs、svn和synergy一样），而git是一个分布式系统（DVCS）。这一点起初可能不那么明显，但它有深远的影响。

• DVCS存储库的克隆包含整个历史记录，因此如果网络断开、服务器没有响应或者你在飞机上等情况下，你仍然可以继续工作、切换分支、提交功能等。
• 由于提交是本地的，你在克隆的存储库中有一个额外的自由度（与分支等正交），你可以通过创建一个特性克隆来处理一个特性，如果不行，只需删除该存储库即可，如果你没有推送，则它永远不会出现在上游存储库的历史记录中。
• DVCS不会规定特定的工作流程。你可以自由地组织团队互动的方式（分层、正交、平面、集中等等）。这是一个很大的优势，可以帮助团队根据设计满足他们的需求。
• GIT（以及hg）直接支持补丁集/棉被等功能，可用于连续集成。在集中式版本控制系统中通常很难做到这一点，因此大多数情况下都不会这样做（我不知道TFS是否具有这些功能）。

- Florian Bösch

---

Git浪费了我太多的时间，这是不可接受的——问题通常与大文件有关。因此，我必须说，如果您计划使用任何大于某个大小的文件，请选择其他工具。 - jlo-gmail