从 Perforce 到 Git：为什么迈出这一步

工作流

抛开所有的花哨，从根本上讲，SCM 工具的核心是协作：让开发人员团队处理一组共享的软件文件。Git 提供简单且计算成本低的分支，这为各种很酷的工作流程打开了大门。任务分支、Git Flow、拷贝存储库——在强大的代码审查和协作工具的帮助下，从开源到专业开发，任何类型的团队都有一个快速简便的工作流程。

Git 还使跨公司的协作变得容易，这是跨职能开发中的常见要求。即使无法通过物理网络访问 Git 共享存储库，Git 补丁和捆绑工具也可以简化数据共享。

另一方面，Perforce 基于每个文件维护分支记录，而 Git 则以每次提交为基础维护分支记录。那是什么意思？好吧，对于初学者来说，每次创建分支时，它都会在 Perforce 数据库中创建大量元数据。这会导致大型部署中的性能问题，以至于许多 Perforce 管理员限制分支创建。

考虑一下：每当您想创建一个任务分支来尝试一项新功能时，都必须去获取权限。如果您无法创建任务分支，那可能需要在主分支上签入不稳定的代码，或者等到“完成”后再提交。这样您就无法享受在任务分支上使用 CI/CD 以及能够跟踪精细的正在进行的工作的好处。最终结果是生产力下降，因为开发人员要么在使用效率较低的工作流程，要么只是开始另外使用 Git 并想出如何手动将其工作合并回 Perforce。

除了昂贵之外，Perforce 分支不利于大多数开发人员偏爱的工作流程类型。Perforce 分支是共享的，因此不存在具有定期变基功能的私有任务分支等东西。而且 Perforce 的合并算法过于复杂，整篇文章都是关于如何合并已重命名或其属性被修改的文件的。

还在 Perforce 服务器之间共享代码吗？您又回来共享没有通用历史记录的 tar 文件了。Perforce 的数据模型认为软件历史记录是单个服务器所独有的，而 Git 可以轻松地在任何地方克隆和共享历史记录。

心灵分享和社区

撇开商业竞争对手，为什么 Git 击败了 Mercurial 和其他有价值的竞争对手？当然，发展势头起到了一定的作用，Git 发展势头很好。Git 由 Linus Torvalds 创建，旨在解决 Linux 内核项目的分布式开发挑战，现在是 Linux、Android、OpenStack 和大多数其他重要开源项目的标准 SCM 工具。优秀人才都在使用这个，因此，如果您是一名招聘经理，您可能会希望新工程师可以（也愿意）在不需要大量培训的情况下使用 Git。

当然，您拥有支持 Git 的充满活力的开源社区的全部力量。Git 正在迅速发展，以解决现实世界中的问题，Git LFS 等主要新功能问世了。如果您想修复某个错误，您可以为 Git 项目贡献自己的代码，而且永远不会被限制在由一家公司设定的路线图和节奏的商业产品中。看看可用的 Git 客户端程序范围：几个强大的桌面 GUI、Windows 资源管理器集成、适用于每个 IDE 的插件和开发人员工具。

GUI 和开发人员工具

在 Git 早期，GUI 和工具支持有些缺乏。对于喜欢使用可视化界面与 Git 存储库进行交互的用户来说，这是一个绊脚石。尤其是游戏艺术家等非技术合作者的权利被剥夺。Perforce 的 Windows 资源管理器插件深受这些观众的欢迎。

但值得庆幸的是，那些日子已经过去了。像 Sourcetree 这样的 GUI 提供了点击式体验，Git 有很多 shell 集成。Bitbucket 提供代码审查、合并和拉取请求、拷贝、在线代码浏览以及大量其他协作工具。事实上，从数据科学家到创意机构，每个人都在组织社区，这些社区利用 Git 和 Bitbucket 实现开放协作。

游戏开发人员很特别

话虽如此，是什么阻止了游戏开发人员和研究人员等处理大数据集的社区加入潮流呢？这一切都要归结为数据类型和项目组织的复杂性。

二进制文件

游戏开发人员，尤其是艺术家，需要处理大型二进制对象，例如纹理和音频资源。数据科学家可能拥有包含数十亿个事件样本的海量数据集。

这给 Git 带来了两个问题。

• 这些文件无法合并，集中式锁定机制很方便，Perforce 也提供这种机制。（但请注意，即使是集中式服务器也只能在单个分支上提供锁定机制，因此依赖此功能意味着您的工作流程非常有限。）
• 这些文件会导致 Git 随着存储库大小的增长而变慢。

存储库大小问题主要由 Git LFS 解决，该扩展允许 Git 处理大型文件，同时将实际文件存储委托给其他地方。

文件锁定问题值得从两个方面展开研究。从软件配置管理角度来看，Git LFS 在路线图中有一种出色的文件锁定功能。Git LFS 将通过一种算法来帮助协调锁定多个分支的二进制文件，无论您在哪个分支上，都能确保您使用的是最新版本。与 Perforce 的单分支锁定模型相比，这为处理大型二进制文件的用户打开了分支工作流程。

将文件锁定视为协调问题也很有用。如果您要开始研究一个无法合并的共享资产，那您如何将这些知识传播给所有感兴趣的各方？同样，这也是使用拉取请求和实时团队协作的现代工作流程的真正亮点。您可以使用 HipChat 快速传达您的意图，并检查特定文件是否有待完成的工作。

考虑一下在大数据时代处理大文件的问题将如何演变也很有趣。为了测试大数据分析作业，您可能需要一个大小为数 TB 的数据集。忘掉任何 SCM 系统——这个项目经过测试并在兼容大数据的文件系统上运行。这里需要的是一个 CI/CD 系统，它可以协调更复杂的管道，将构件存放在 HDFS 或 S3 上。这就引出了我们的下一个话题。

大型项目

游戏开发是包含多个模块或组件（游戏引擎、用户界面、静态艺术、视频渲染等）的软件项目的典型示例。Perforce 作为一个单体式集中存储库可以在单个服务器中托管所有这些模块，并允许用户选择在自己的工作区中挑选哪些部分。

但是，这种优势现在基本上没有实际意义。像 Bitbucket 这样的现代 Git 系统可以更轻松地管理 Git 多模块工具，如子模块和子树。更重要的是，像 Android 这样的大型项目已经展示了如何使用更高级别的合成工具来管理复杂的项目。其中许多经验教训已被引入现代 CI/CD 工具，例如 Bamboo 和 Bitbucket Pipelines，它们可以协调复杂的持续集成工作流程，对项目之间的依赖关系进行建模，并管理项目之间的构件。

这种趋势在很大程度上遵循了 Git（和 *nix）的理念，即构建一个能很好地完成单项工作的工具。持续集成和持续交付 (CI/CD) 本身就是一种实践，其工具专门用于理解构建和发布工作流程。它还符合现代软件开发最佳实践，后者旨在使用小型的独立微服务而不是单体式项目。

下一步

“Perforce to Git” 阵营显然有一些势头，Git 和现代 CI/CD 工具现在已经准备好应对规模最大、最复杂的开发工作。事实上，Perforce 甚至开发了一个名为 Git Fusion 的工具，它允许您将中央 Perforce 存储库的一部分提取为 Git 代码存储库。

不幸的是，尽管 Git Fusion 是一项崇高的工作，但尝试将 Git 分层到集中式 SCM 系统上并不是一件容易的事，如果您试图混合使用模式，很容易破坏一个系统的数据视图。如果您不混合使用模式，就很难看出在 Git 后面使用商业集中式后端的价值。我们所看到的趋势实际上是朝着另一个方向发展：如何将最后剩下的几个有用的集中式 SCM 放入 Git 中？

如果您使用 Perforce 进行任何软件或游戏开发，您可能想知道（紧张）如何迁移到 Git。您到底是怎么做到的？转换成本值得吗？这正是我们将在下一篇文章中介绍的内容。