274

我向我的开发团队介绍了 Git,除了我之外,每个人都讨厌它。他们想用 Team Foundation Server 替换它。我觉得这是一个巨大的倒退,虽然我对 TFS 不是很熟悉。有经验的人可以将 TFS 上的分支支持与 Git 分支进行比较吗?另外,总的来说,TFS 的优缺点是什么?使用 Git 几年后我会讨厌它吗?

4

9 回答 9

286

我认为,声明

每个人都讨厌它,除了我

浪费任何进一步的讨论:当你继续使用 Git 时,如果出现任何问题,他们会责备

除此之外,对我来说,与我最欣赏的集中式 VCS 相比,Git 有两个优势(正如Rob Sobers部分描述的那样):

  • 整个 repo 的自动备份:每次有人从中央 repo 中提取,他/她都会获得完整的更改历史记录。当一个仓库丢失时:别担心,在每个工作站上拿一个。
  • 离线回购访问:当我在家工作(或在飞机或火车上)时,我可以看到项目的完整历史记录,每次签到,无需启动我的 VPN 连接即可工作,并且可以像工作中一样工作:签入,结帐,分支,任何东西。

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

如果他们只是不想要它,因为它对他们来说是新的并且不愿意学习新东西:你确定你会和那个员工一起成功地发展吗?

真的每个人都讨厌 Git,还是受到某些意见领袖的影响?找到领导,问他们有什么问题。说服他们,你就会说服团队的其他成员。

如果你无法说服领导者:忘记使用 Git,使用 TFS。会让你的生活更轻松。

于 2010-12-11T12:24:30.057 回答
114

两个系统的关键区别在于 TFS 是集中式版本控制系统,而 Git 是分布式版本控制系统。

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

在开发人员的机器上拥有完整的存储库的一个好处是在服务器死机的情况下提供冗余。另一个不错的好处是,您可以在修订版之间来回移动您的工作副本,而无需与服务器交谈,这在服务器关闭或无法访问时会很有帮助。

对我来说,真正的好处是您可以将变更集提交到本地存储库,而无需与服务器交谈或对您的团队造成潜在的不稳定更改(即破坏构建)。

例如,如果我正在开发一个大功能,我可能需要一周的时间来编写代码并对其进行完全测试。我不想在周中签入不稳定的代码并破坏构建,但是如果我接近周末并且不小心破坏了整个工作副本会发生什么?如果我一直没有承诺,我将面临失去工作的风险。这不是有效的版本控制,TFS 很容易受到这种影响。

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

我什至没有深入探讨 DVCS 中的分支和合并有多好,但您可以在 SO 或 Google 上找到大量解释。我可以根据经验告诉你,TFS 中的分支和合并并不好。

如果您的组织中 TFS 的论点是它在 Windows 上比 Git 更好地工作,我建议 Mercurial,它在 Windows 上工作得很好——它与 Windows Explorer (TortoiseHg) 和 Visual Studio (VisualHg) 集成。

于 2010-12-11T04:41:39.950 回答
87

人们需要放下枪,离开壁架,想一想。事实证明,DVCS 具有客观、具体和不可否认的优势,这将对团队的生产力产生巨大影响。

这一切都归结为分支和合并。

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

现在,有了 DVCS,分支(和合并)有了很大的改进,其指导原则是“马上做。它会给你带来很多好处,而且不会给你带来任何问题。”

这对任何团队来说都是一个巨大的生产力助推器。

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

但是一旦你看到这一点,你甚至不会考虑选择非 DVCS。因为 DVCS 确实有明确、客观、具体的优势,最大的胜利在于分支和合并领域。

于 2011-02-06T06:28:49.017 回答
45

原文:@Rob,TFS 有一个叫做“搁置”的东西可以解决您对提交正在进行的工作而不影响官方构建的担忧。我意识到您将中央版本控制视为一个障碍,但就 TFS 而言,将您的代码检查到货架上可以被视为一种优势 b/c 然后中央服务器在极少数情况下拥有您正在进行的工作的副本您的本地机器崩溃或丢失/被盗,或者您需要快速换档。我的观点是,TFS 在这方面应该得到应有的赞扬。此外,TFS2010 中的分支和合并已从以前的版本中得到改进,当您说“......根据 TFS 中的分支和合并不好的经验”时,不清楚您指的是哪个版本。免责声明:我是 TFS2010 的中度用户。

编辑 2011 年 12 月 5 日:对于 OP,TFS 困扰我的一件事是,当您不处理它们时,它坚持将所有本地文件设置为“只读”。如果您想进行更改,流程是您必须“签出”文件,这只是清除文件上的只读属性,以便 TFS 知道要密切关注它。这是一个不方便的工作流程。我希望它工作的方式是自动检测我是否进行了更改并且根本不用担心/打扰文件属性。这样,我可以在 Visual Studio、记事本或任何我喜欢的工具中修改文件。版本控制系统在这方面应该尽可能透明。有一个 Windows 资源管理器扩展(TFS PowerTools) 允许您在 Windows 资源管理器中处理文件,但这并不能大大简化工作流程。

于 2011-02-04T02:53:05.023 回答
17

除了所说的一切(

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 提供一站式目的地的地方。

于 2012-03-20T21:48:23.060 回答
16

如果您的团队使用 TFS 并且您想使用 Git,您可能需要考虑使用“git 到 tfs”的桥梁。本质上,您在计算机上使用 Git 进行日常工作,然后当您想要推送您的更改时,您将它们推送到 TFS 服务器。

那里有几个(在github上)。我在最后一个地方(与另一位开发人员一起)使用了一个并取得了一些成功。看:

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

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

于 2012-06-19T15:55:14.050 回答
14

经过一番利弊调查后,我参与的公司也决定选择 TFS。不是因为 GIT 不是一个好的版本控制系统,而是因为 TFS 提供的完全集成的 ALM 解决方案最重要。如果只有版本控制功能很重要,那么选择可能是 GIT。然而,对于普通开发人员来说,陡峭的 GIT 学习曲线不容小觑。

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

于 2012-03-21T23:16:28.873 回答
13

Git 的整个分布式真的很棒。它提供了一些 Shelvesets 不具备的功能(在当前产品中),例如本地回滚和提交选项(例如Eclipse 的 localhistory 功能)。您可以使用开发人员分支来缓解这种情况,但说实话,许多开发人员不喜欢分支和合并一点。我经常被要求在 TFS 中打开旧式的“独家结帐”功能几次(并且每次都被拒绝)。

我认为许多大型企业都非常害怕允许开发人员将整个历史记录带入本地工作空间并随身携带(例如,给新雇主)......窃取快照是不好的,但会带走整个历史记录就更麻烦了。(并不是说您无法从 TFS获得您想要的完整历史记录)...

有人提到这是一种很好的备份方式,这对于再次开源非常有用,原始维护者可能会停止关心并删除他的版本,但是对于企业计划而言,这对于许多企业来说又是不足的,因为没有明确的责任分配保留备份。如果主“项目”不知何故消失,将很难确定使用哪个版本。这往往会指定一个存储库作为领导/中央存储库。

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

我还想补充一下非源代码控制区域中提到的内容。工作项目跟踪、报告和构建自动化(包括实验室管理)等功能极大地受益于中央领先的存储库。当您使用纯分布式模型时,这些会变得更加困难,除非您使其中一个节点处于领先地位(从而回到分布较少的模型)。

随着 TFS 11 附带 TFS Basic,期待分布式 TFS 可能并不遥远,它允许您在 TFS 12+ 时代将本地 TFS 基本同步到中央 TFS。我会在 uservoice 中投下我的一票

于 2012-03-21T15:39:39.387 回答
9

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

于 2011-05-05T14:10:18.273 回答