多年来，许多游戏团队只在版本控制出问题时才会想到它。

设计师覆盖了蓝图；美术师在共享场景中丢失了工作成果；外包人员等待数小时才完成项目同步；构建管线因为仓库过于庞大而无法跟上生产节奏，导致速度下降。这些不再是罕见的边缘情况。对于许多工作室来说，它们已经成为现代游戏制作日常阻力的一部分。

这种摩擦正是越来越多的游戏团队开始质疑其生产管线底层工具的原因之一。在软件开发中，Git 仍是默认选择，Perforce 也依然深度嵌入大规模游戏生产。但随着团队更加分散、项目愈发庞大、制作预算压力增大、创意流程更加复杂，这两套系统都被推向了它们最初并非为应对的领域。对于那些希望在不过度增加基础设施、维护和许可开销的情况下进行扩展的工作室来说，问题不再仅仅是他们的版本控制是否有效，而是它是否仍然适合当今的游戏生产方式。

Diversion 正围绕这一转变构建其解决方案。

该公司将其平台描述为适用于游戏开发、Unreal Engine、Unity、3D 和 AI 工作流的可扩展版本控制。实际上，它的观点很简单：游戏工作室不应该被迫在“以代码优先但难以处理大型二进制资源”的工具和“能够应对规模但往往带来运营开销”的传统企业系统之间做选择。

传统版本控制最初是一种工程解决方案。代码是主要资产，文件相对较小，合并基于文本的变更只是工作流中可控的一环。游戏制作使这种模式变得复杂。一个现代项目可能包含代码、3D模型、纹理、动画、音频文件、地图、蓝图、Unity 预制体、配置数据，以及无法像源码那样合并的大型二进制资源。

“游戏开发中的版本控制不仅仅是代码。一个典型项目包含代码、3D模型、纹理、音频、动画、关卡文件、配置，以及蓝图或 Unity 预制体等引擎特定资源。这些文件通常很大、是二进制的，并且由非工程师人员操作。

挑战在于，大多数版本控制工具是为源代码设计的。Git 假设文件是小型文本文件，用户具备技术能力，并且合并操作简单直接。游戏项目打破了所有这些假设。

Perforce 能更好地处理游戏项目，但部署和运营成本高昂，需要持续维护，并且会限制分支和与现代开发工具集成等现代工作流。”

——Sasha Medvedovsky，Diversion 联合创始人兼 CEO，接受 80 Level 采访。

这种区别很重要，因为版本控制已经不仅仅是工程问题。工程师、美术师、设计师、音频团队、制作人以及外部合作伙伴都需要在同一个生产环境中工作。如果版本控制系统只有程序员觉得顺手，其他团队成员往往会绕过它。而这些绕道操作可能带来风险。

Git 在处理文本文件、分布式工程工作流以及能够干净合并的变更时最为强大。游戏项目通常涉及数十万个文件，其中许多是大体积的二进制文件。即使有了 Git LFS，随着项目增长，仓库也会变得更慢、更复杂。

与此同时，Perforce 长期以来一直是大规模游戏制作的中坚力量，因为它能更高效地处理大文件和文件锁定工作流。但它带来的成本也不同：基础设施、服务器管理、IT 支持、许可、维护和内部专家知识。对某些团队而言，这是可控的；对另一些团队来说，它又成了额外的生产负担。

Diversion 的赌注是，新一代工作室想要的是不同的东西：企业级版本控制所具备的规模和文件锁定纪律，但工作流更贴近现代团队实际工作的方式。

该平台已经用于数万个项目，数百家商业工作室和数千名独立游戏开发者正在使用 Diversion。除游戏外，其客户群还包括虚拟制作工作室、建筑可视化团队、VR 和 3D 公司以及 AI 初创公司。

这些客户之一就是 Creatures Inc.，他们将 Diversion 用于其开发工作流的一部分。

大型文件问题是 Diversion 方法的核心。该公司表示，团队无需像在传统基于 Git 的工作流中那样将“大文件”与“常规文件”分开，无需配置 LFS，也无需考虑特殊跟踪规则。根据其基准测试，Diversion 可以在 30 秒内提交 40 万个文件，并在 5 分钟内克隆包含 500 万个文件的仓库。

对于游戏团队来说，这样的数字不仅仅是技术声明。它们指向了一个实际的生产问题：当同步、克隆或移动资源耗时过长时，人们就会不再信任管线。工作开始在系统之外进行，文件通过聊天、硬盘或手动导出传递。这种情况越多，生产就越脆弱。

冲突预防是 Diversion 定位的另一大重点。在游戏开发中，许多最重要的文件无法干净合并。如果两个人同时改同一个蓝图、地图、场景或预制体，除非团队在冲突发生前加以阻止，否则其中一人的工作可能会丢失。

Diversion 试图将这种预防带入开发者已经使用的工具中。该公司为 Unreal Engine 和 Unity 提供原生插件，将版本控制直接带入编辑器。在 Unreal 中，当其他用户正在编辑某个文件时，插件会在打开和保存该文件时发出提醒。对于不能并发编辑的资源，Diversion 还支持硬锁（hard locks），为一个用户提供独占写权限，直到锁被释放。

具体到蓝图，Diversion 与 Unreal Engine 内置的可视化合并工具集成，允许冲突发生时在编辑器中以可视化方式解决。但该公司更广泛的理念是：预防比事后清理更重要。

“冲突预防是我们投入最多的功能之一，因为它对游戏开发至关重要。大多数游戏资源是二进制的，当两个人不知情地编辑同一文件时，就会有人丢失工作成果。

我们的主要方法是在冲突发生前进行预防。当你打开一个他人正在编辑的文件时，编辑器内会立即弹出提醒。这在 Unreal Engine 插件和 Unity 插件中都有效。你在打开文件和尝试保存时都会看到提醒。对于绝对不允许并发编辑的文件，我们还支持硬锁，即一个人获得独占写权限，直到他释放为止。”

——Sasha Medvedovsky，Diversion 联合创始人兼 CEO，接受 80 Level 采访。

迁移也成为讨论中越来越重要的一部分。工作室很少会在一天之内更换版本控制系统，尤其是在制作已经进行中的时候。Diversion 的做法就是降低这种过渡的风险。
对于从 Perforce 迁移而来的团队，该公司支持双向同步，让工作室在过渡期间保持 Perforce 和 Diversion 仓库同步。这意味着团队可以逐步迁移，按项目或按部门进行，而不是为了一次性切换系统而暂停制作。

对于从 Git 或 GitHub 迁移而来的团队，Diversion 支持导入带历史的仓库，让团队可以将现有项目导入 Diversion，而无需从零开始。

这种渐进式方法很重要，因为版本控制与工作室的工作方式紧密相连。它涉及源代码、美术、构建、权限、审查、自动化和外部协作。会中断制作的迁移通常并不现实。而能够让团队分阶段测试、导入、同步和过渡的迁移方式，更符合工作室的实际运作方式。

整个行业如今越来越关注大文件版本控制。Epic Games 最近发布了 Lore，一个面向大型游戏和娱乐项目的开源版本控制系统。从很多方面来看，Lore 验证了 Diversion 一直关注的问题：Git 和 Perforce 并不是为现代游戏制作的所有需求而设计的。

Diversion 认为，Lore 对行业来说是一个积极的信号，但它并不是同类产品。Lore 是一个开源版本控制引擎，由工作室自行托管和构建。Epic 自己的文档将 Lore 描述为 0.x 预稳定版本，其 API 和协议在稳定 1.0 版本发布前可能仍会演变。Epic 还表示，并不期望工作室在一夜之间更换现有工具，并将当前阶段定位为团队进行探索、原型设计并帮助塑造项目的时期。

“Lore 对行业来说是一个积极的进展。Epic 投资于专门为大型文件构建的 VCS，这验证了我们多年来的说法：Git 并不是为此而设计的，游戏团队理应拥有更好的工具。这个问题受到的关注越多越好。

也就是说，目前的 Lore 仍然处于预稳定阶段，并没有被定位为现有制作工具的一夜替代品。它提供了一个核心版本控制引擎，但工作室围绕该引擎所需的大部分内容——基础设施、托管、用户管理、CI/CD 集成、编辑器工作流、权限和生产支持——仍然需要构建、集成或维护。

Diversion 是一项完全托管的服务。你注册后就可以开始使用。无需部署服务器，无需配置 AWS 后端，也无需随着团队增长扩展基础设施。而且，我们为所有客户提供出色、直接的支持。”

—— Sasha Medvedovsky，Diversion 联合创始人兼 CEO，接受 80 Level 采访

版本控制很少被视为创意工具。但在游戏开发中，它直接影响到团队进行试验的安全性和速度。如果美术师不敢触碰共享关卡，如果设计师在 Blueprint 上丢失工作，如果外包人员整天等着资产同步，那么制作管线就会以容易被低估的方式影响创作过程。

这才是转变背后更大的故事。工作室不仅在寻找更快的同步或更好的文件锁。他们寻找的是符合当下游戏制作现实的版本控制：跨越各个专业领域、跨越地点、跨越引擎，以及跨越充满资产的大型仓库，而这些资产的行为与代码截然不同。

Diversion 押注于越来越多的工作室已经准备好超越 Git 开发者优先模式与 Perforce 操作负担之间的旧有取舍。现代游戏团队需要一种从一开始就理解制作的版本控制——不只是作为存放代码的地方，而是作为让创意工作持续运转的系统。

对于想了解 Diversion 实际运作方式的团队，可以通过Diversion 网站。

相关链接

• Diversion website

原文链接：https://80.lv/articles/game-studios-are-moving-beyond-legacy-version-control-and-here-s-why