8

我们将在我工作的公司开始一个新项目。这是一个 C++ 和 C# 软件开发项目，在三个地点有大约 6-8 名开发人员。

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

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

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

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

4

2 回答 2

8

好吧，我不能给你一个完整的答案。但是我们查看了用于 Java 开发的 TFS，这里有一些您可能也会感兴趣的观点。

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

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

再说一遍：我们尝试（或不得不尝试）使用 TFS + Java，而使用 C# + Visual Studio 则完全不同。那里的整合会更好。然而我的一些观点可能仍然有用:)

于 2012-10-08T11:36:37.650 回答
4

我无法具体评论 TFS，因为我唯一的体验是简短且非常不愉快，所以我不会。

然而，我确实经常使用 git 和 github（以及企业版），并且我使用过各种集中式 VCS（rcs、cvs、svn、synergy）和分散式 VCS（hg、git）。

我认为 GIT 和 TFS 之间的主要区别除了一些辅助功能差异外，基本上 TFS 是一个集中式系统（如 rcs、cvs、svn 和 synergy），而 git 是一个分散式系统（dvcs）。乍一看，这似乎没有太大的区别，但它具有深远的意义。

  • dvcs repo 的克隆包含整个历史记录，因此您可以继续工作、切换分支、提交功能等。如果网络出现故障、服务器没有响应、您坐在飞机上等。
  • 由于提交是克隆存储库的本地提交，因此您有一个额外的自由度（与分支正交等），您可以通过对存储库进行功能克隆来处理功能，如果不起作用，只需删除存储库如果您不推送，它将永远不会进入上游存储库的历史记录。
  • DVCS 并不规定特定的工作流程。你可以自由地以任何你想要的方式构建你的团队交互（分层、正交、扁平、集中，你有什么）。这是一个很大的优势，可以帮助团队成长（和缩小），而不会留下无法通过设计满足其需求的系统。
  • GIT（以及 hg）直接支持补丁集/被子之类的东西，可用于持续集成。这通常在集中式 VCS 中很难做到，所以大部分都没有完成（我不知道 TFS 是否有这些功能）
于 2012-10-08T14:40:56.743 回答