Perforce 用户文章转载：每个游戏从业者都应该学学 P4

本篇作者向华是一名游戏行业从业者，也是 Perforce 用户。

提到版本管理，可以联想到 SVN、Git 等常见的 VCS（Version Control System）工具，它们广泛应用于软件行业。

而在游戏行业中，越来越多的游戏公司使用 P4 作为游戏研发体系中 VCS 的基础设施，国外游戏厂商 Epic 使用 P4 组织开发虚幻引擎和游戏项目，而腾讯、米哈游、网易等国内游戏厂商无一例外也在使用 P4。

一款游戏从立项到上线，是一个迭代快、周期短、发布多的研发过程。项目会经历几十周版本迭代和数次对外测试发布后，与玩家正式见面。上线后还会有大量的版本迭代工作继续进行。可以说，整个游戏研发过程中生成的资产文件是海量的，文件之间的逻辑引用关系和生成关系也是复杂的。

这主要是因为游戏项目是依靠策划数据、程序代码、美术资源、音乐音频、测试框架和构建脚本来产出每一个版本，每个开发人员产生的内容及内容之间的耦合程度都是复杂多变的。一个游戏团队普遍会将组成项目的各类文件拆分成多个并行分支，按照开发日程表，在每个分支上安排不同的 Team 或人员完成开发、测试和版本构建，然后通过分支间的集成，将每个人的工作内容体现在最终可发布的产品当中。

那么如果是单一的开发分支，会不会更简单？

如果是单一分支，可能只需要考虑文件并行修改引发冲突的问题，然而现实的游戏开发绝不会是单一的分支。游戏越来越重度，包体资源越来越大，只有多分支间的协同并行开发，最终再集成的方式才能够帮助团队在有限的时间内完成内容发布。

另外游戏开发与其他软件开发一样，开发和迭代过程中不可避免地会产生各种 bug 和流程问题，比如游戏启动黑屏，游戏功能报错/闪退等严重问题，此时项目组需要通过文件的在 VCS 中的集成历史来完成问题定位。

游戏研发和发布对 VCS 的要求。

• 需要能够在各分支下进行持续迭代，支持清晰的开发和发布生命周期；

• 需要能够便捷回溯仓库中任意文件的版本集成历史，包括该文件在所有分支上的版本演化历史与分支间的集成历史（添加、删除、合并、重命名、移动位置等）；

• 需要能够帮助开发者方便解决文件间复杂的组织关系和并行开发导致的冲突；

• 需要能够方便开发 CI/CD 工具，用于研发过程中所有流程的自动化和标准化；

• 最好能够能够支持跨地域团队协作。

可以想象一下，类似原神、堡垒之夜这类支持 PC、Mobile、Playstation 等多平台的大制作，不同平台对游戏工程的资产带来的多样性影响很大。

为了完成这些多平台多版本的持续稳定交付，各大游戏厂商的毫不犹豫地指向了 P4。

那到底什么是 P4？

P4 是 Perforce Software 的简称，同时也是 Perforce 的命令行名称。

而 Perforce 是一款 SCM 软件（软件配置管理系统），其中包含 VCS 功能，它能够跟踪软件工程师所构建的软件及其所有组件。

P4 有哪些特点？

从实践角度来讲，Perforce 具备以下一些突出的特点。

Changelist（变更列表）

Changelist 是一个很具特色的概念，它可以将同一时间段内修改的文件捆绑成一组变更作为独立的工作单元。如果观察 P4 的提交记录，可以看到仓库中的每一次变更都可以追溯到一个 changelist ，并且每个 changelist 都代表着仓库的一次变更历史，只有开发者本地的 changelist 被提交成功时，仓库才会向前演进。

开发过程中，操作一个 changelist 是原子事务，而不是操作文件。对于项目而言，最好的实践每个 changelist 都是一组有关联关系的文件变更的组合。

Mainline Model

P4 通过 Stream 的概念实现了 Mainline 模型，这一模型可以智能地确定集成规则：哪些变更可以在哪些条件下完成集成。

举个实际点的例子。

Dev 分支是从 Main 分支中拉出来的，经过一段时间的开发和测试，终于可以集成到 Main。然而，在 Dev 分支开发的这段时间里，Main 分支也在紧锣密鼓地接受开发人员的变更提交。在从 Dev 分支向上 copy 到 main 分支之前，要确保 Dev 分支已经拥有了这段时间内 Main 分支的所有变更，所以集成规则是先将这段时间 Main 分支的变更向下 merge 到 Dev 分支，再将 Dev 分支向上 copy 到 Main 分支。

Rel 分支是一个已经外放的分支，如果出现线上 bug，修复和测试都发生在 Rel 分支这条线上。由于 Rel 早先也是从 Main 分支拉出来，所以 Main 分支也需要这些 bug 修复。在这种情况下，Mainline 模型支持开发者将 Rel 分支的文件向下 merge 至 Main 分支，但不能从 Main 分支 copy 任何变动到 Rel 分支，因为 Rel 分已经在发布中，理论上不能再接受新的 feature，除非再拉出 Rel_2 分支（包含目前最新的 Main 分支的所有已开发完成内容）。

变更集成与变更跟踪

在 P4 的知识体系中，merge 和 copy 两个操作都属于集成操作。集成操作和其他所有的用户操作一样，操作历史都会被记录在 Perforce 的服务器日志中。

对于单个文件，P4 提供了一款强大的内置工具 —— Revision Gragh，用可视化的方式快速帮助开发者确定文件的变更走向。

曾经有个印象深刻的使用场景，仓库中的某文件在分支合并的过程中被人删除掉了，游戏因此报错，定位问题时需要查看该文件的变更的历史走向，在 P4 的图形 GUI 软件 P4V 中，点击 Revision Graph，一图在手，历史尽有。可谓实用性满分，用过的都说好！

用 Git、SVN 也挺美的，能不能不学 P4？

简单来说，P4 能够应用于游戏大厂说明这是一个风向标，也是未来游戏工业化浪潮的趋势所在，选择在每个人的手中，特别是爱学习、优秀的游戏人。

写在最后

以上内容是个人在工作实践中的一些总结整理，供各位参考。

祝愿每位游戏人都能

提交顺利不卡壳，产品赚钱没 bug。

感谢阅读:-)

-- 本篇结束 --

你好，我是向华。

一个飞驰在高速路上的游戏从业者。欢迎一键三连，也可下次一定。

立刻联系我们（Perforce 中国授权合作伙伴、Atlassian 全球白金合作伙伴【龙智】，电话：400-7755-506 邮箱: marketing@shdsd.com）了解更多关于使用 Jira, Confluence, Perforce Helix Core, Helix QAC, Hansoft, Methodics, Helix ALM 等产品的信息。我们将为您提供白皮书和其他资源，我们也会指导您运用 Perforce 系列产品来开展业务。