几乎每次我在某个地方做某种演讲时，人们都会问我如何说服他们的管理层放弃 Microsoft Team Foundation Server 的源代码控制系统并转移到 Git 的 建议。在这篇文章中，我将只讨论源代码控制系统。 Visual Studio Online （Microsoft 的 TFS-in-the-cloud）、 GitHub 和 BitBucket 都大力支持这一点。我们自己使用 GitHub，但我注意到，自从我们放弃 TFS 后，Microsoft 做出了一些相当大的改进。
不管怎样，在 2014 年 1 月，在使用 TFS 三年之后，我们终于转向了 Git。凭借 1.5 年的经验，我认为我们有权对它们的比较方式发表意见。为了帮助我编写这篇博文，我询问了我的同事关于他们现在可以做的事情，而这些事情在我们仍在使用 TFS 的集中式源代码控制系统时是不能做的。
- 您可以在几秒钟内创建和合并分支，而不是几分钟（如果您的项目非常简单，则需要几小时）。分支之间的切换以毫秒为单位，而不是我们项目中通常的 15-30 分钟。这完全改变了您的工作方式。它允许使用集中式源代码控制系统无法实现的隔离级别。
- 拉取请求 (PR) 是所有在线 Git 平台都支持的一项功能，它是团队在不阻止任何人的情况下分解团队拥有的组件中的复杂软件系统的重要工具。它允许开发人员制作他们不拥有的项目的某种副本，创建分支，致力于改进和新功能，然后向拥有团队发送请求以引入他们的更改。合并请求是将软件开发组织扩展为多个自治团队的最佳方式。
- 您多久遇到一次无用的评论，例如“哎呀，我破坏了构建”或“一些审查返工”。您可以在将功能分支合并到其最终位置之前清理功能分支的历史记录，方法是使用交互式变基来修改现有提交（相当于 TFS 变更集）、将几个提交压缩在一起或修复这些提交注释.
- 开发人员可以通过与其他团队成员合并，在同一分支上并行工作，无论是从中央存储库还是在各个团队成员拥有的分支上。如果他们愿意，他们可以使用 PR 来控制共享分支中的内容。
- 所以您已经在该功能上工作了一周左右，但与此同时，主要开发分支已经发生了相当大的变化。如果您可以在那个较新的分支上应用您的更改，就好像您首先从该版本开始一样，那不是很酷吗？好吧，这就是 Git rebase 可以为您做的。它保持历史清洁并避免所有那些不可读的合并。
- 与我们使用 TFS 的时间相比，我们现在在 Git 上的合并冲突要少得多。主要原因是 Git 进行了 三向合并 ，因为它确切地知道两个分支从哪里开始分叉。 TFS 通常会执行非常愚蠢的基于文本的合并。您还可以控制在该特定项目中如何处理每个文件类型的合并。
-
您永远不必明确检查任何内容。只需使用您喜欢的任何工具编辑文件，Git 就会选择它。该项目的 .gitignore 文件确保它只会监控特定文件。如果您更改的最终结果是您根本没有进行任何更改，Git 将不会再将该文件视为已更改。告别所有那些包含未修改文件的 TFS 变更集。我们确实尝试了 TFS 的 Local Workspaces 功能，但它因大型存储库而崩溃。
-
您在线上可以做的所有事情都可以离线进行。去年，我在瑞士旅行了几天。您可以从本地笔记本电脑进行分支、合并和变基这一简单事实是您真正开始重视的事情，如果您可以在没有互联网连接的情况下做到这一点。当我客户项目的互联网连接中断时，这变得很有帮助。您甚至可以通过本地网络共享或 USB 驱动器与其他同事的存储库合并。
-
由于 Git 将分支视为指向提交链表的指针，因此包括所有分支和标签在内的整个源代码可以在几分钟内下载，如果不是几秒钟的话。
-
最后，就连微软也跳了出来。 Git 现在是 TFS 内部部署版本和 Visual Studio Online 的主要源代码控制系统。微软正在 Github 上维护整个 .NET 框架。
如果您仍然无法用这些论据说服您的老板，请告诉您的老板您可以使用 Git 提高多少工作效率。或者，您可以通过坚持使用集中式源代码控制系统告诉他或她他每天浪费了多少钱来扭转这种争论。
所以你怎么看？你要搬过来吗？我错过了任何我应该包括的好的论据吗？我是否夸大了其中的任何一个？通过在下面发表评论或在 @ddoomen 发推文让我知道。