独立游戏开发中的版本控制

前言

最近，笔者打算做一些基于虚幻引擎的小 Demo，用来学习和研究。由于此前已习惯用公司内部的协作流程和工具，再加上我又是个喜欢折腾的人，这次正好花时间研究一下，现在有哪些比较适合独立开发者或个人使用的版本控制方案。在此过程中做了一些尝试，当然也踩了一些坑。由于我并非版本控制领域的专家，这篇文章更多是个人看法以及折腾过程的分享，希望可以抛砖引玉。

独立游戏开发对版本控制的需求分析

在聊版本控制的问题前，我们先来说说什么是独立游戏。

目前，独立游戏还没有统一的定义，但大体是指那些具有“独立精神” 的作品。这类游戏有别于商业 3A 大作，它们往往更注重创意的表达。独立游戏开发者常常需要自己承担开发过程中的花费，但与之相对，他们也能自主决定游戏的走向。

这里有两个关键——自行承担开发花费，以及自主决定作品走向。

自由，也许是独立游戏开发者最能（最希望）感知到的工作特点。这在版本控制工作流的设计中往往意味着：

独立开发者不需要维持过于复杂的工作流程；
独立开发者不需要同大型团队协作；
独立开发者不能够承受太多软件授权费用；
独立开发者没有过多 IT 基础设施和精力来维护这个系统；
独立开发者的代码仓库不需要过于复杂的自动化管线（CI/CD）。

直白讲就是，独立开发者需要的是一套部署简单、维护成本低、上手速度快，同时适合小型团队的版本控制系统。

维护一套合适的的版本控制系统，不仅仅是为了保存工作成果，方便回滚，管理开发进度，也可以整体提高协作和开发效率。

常用版本控制系统介绍

Git

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. —— Git 官网

Git 于 2005 年以 GPL 许可协议发布。它最初由 Linux 之父 Linus 研发，是用于管理 Linux 内核代码的版本控制工具。不同于当时采用集中式服务器的其他版本控制工具，Git 是分布式的。分布式意味着 Git 可以脱离服务器运行，也可以说每一个 Git 用户的本地计算机都是一个 Git 服务器。这让 Git 的工作原理有些不太好理解，因为 Git 不关注具体的文件版本，而是关注每一次提交的历史记录。

Git 使用命令行来进行工作，任何安装了 Git 的电脑都可以找到一个名为 git 的命令。

git init: 在当前目录创建一个新的 Git 仓库。
git clone [repository]: 克隆一个远程 Git 仓库到本地。
git add [file]: 将文件添加到暂存区，准备进行提交。
git commit -m "commit message": 提交暂存区的文件到本地仓库，并附上一条提交消息。
git push: 将本地仓库的提交推送到远程仓库。
git pull: 从远程仓库拉取最新的代码到本地。
git branch: 显示当前仓库的分支列表。
git checkout [branch]: 切换到指定分支。
git merge [branch]: 将指定分支的更改合并到当前分支。

同时，Git 也有许多 GUI 工具。比如 Github 推出的 Github Desktop，不仅可以为用户提供 Git 命令的图形化操作，还集成了 Github 本身的一些功能，方便用户从 Github 管理代码。除了 Github Desktop 以外，还有 TortoiseGit 这类将 Git 操作集成到 Windows 右键菜单的工具，以及 Fork 这样功能全面的桌面应用程序。

不仅如此，许多 IDE 也集成了 Git 的功能。比如 Visual Studio、JetBrains 系列 IDE，以及 VS Code 这款常用的文本编辑器。开发者可以直接以插件或者软件内部 Tab 页的方式执行 Git 操作。

Perforce

Perforce （后文简称 P4）是一个集中式版本控制系统，性能优越，且能够处理较大的用户数量和文件数量，所以被广泛应用于游戏开发和大规模企业级项目中。

Perforce 有一个负责存储版本信息的中央服务器（P4D），有管理员客户端（P4A），还有一种命令行工具（P4）以及 GUI 界面（P4V）来实现各种操作。概念 Depot 是 P4 中的仓库，类似于 Git 的 Repository，只有管理员可以使用 P4A 创建新的 Depot，这一特性使得个人用户使用 P4 变得麻烦。它并不像 Github 那样，任意用户通过一个网页上的按钮就可以新建一个仓库。

图片：P4 官网（https://www.perforce.com/）

此外，Stream 的机制导致 P4 的分支创建功能更加不易使用，客户端提供的操作也比 Git 更多更杂。虽然常用的操作只有 Get 和 Commit，但要完全理解 P4 的设计哲学并不那么容易。比如 checkout、shelve、workspace、copy/merge、target/source、depot/stream 等概念，经常会令新接触 P4 的用户一头雾水。

其他

Mercurial：Mercurial 也是一个分布式版本控制系统，它的设计目标是简单易用。Mercurial 的操作相对直接，对于那些不需要复杂功能，或者青睐简便高效工具的团队来说，Mercurial 是一个好的选择。

Subversion (SVN)：Subversion（简称 SVN）曾经是版本控制系统的领导者，无论在开源项目还是企业应用中，都占有可观的份额。尽管分布式版本控制系统（如 Git 和 Mercurial）逐渐普及，但 SVN 仍被一些团队和项目广泛使用，特别是那些在 Git 诞生之前就已存在的项目。

Plastic SCM：Plastic SCM 是一种版本控制系统，特别针对部分游戏公司处理大量大型二进制文件的需求。Plastic SCM 提供了一种所见即所得（WYSIWYG）的分支和合并体验，这对游戏开发公司颇具吸引力。

总结

此处，笔者仅就自己使用过的两种版本控制系统进行对比，总结如下：

对比项目	Perforce	Gitlab
易用性	中	低
功能	仅版本控制	Git、Codereview、CI/CD 等
性能	高	一般
是否分布式	中心式	分布式
价格	免费版仅 5 个用户，20 个工作区。超出需付费	基础功能全部免费，少数额外功能收费
部署/维护难度	中等（需要有相关知识的管理员）	简单（任何开发人员都会设置）

大家都在用什么版本控制系统

游戏公司对版本控制系统的主要需求，是管理巨量二进制文件。这些文件包括美术资源的原始资产，以及导入到引擎的二进制美术资产（如材质和贴图），还有引擎自定义的二进制文件格式。除此之外，还需要满足团队协作的需求，例如，如何协调不同工作室的开发内容，确保多个工作室能够高效配合。而在协作过程中，安全性是首要问题，需要考虑如何对用户进行认证，以及如何保证仓库不被未授权者访问。有些时候，还会有一些自动化的需求，比如在编译版本时自动发送邮件提醒，以及集成持续集成和持续交付（CI/CD）等需求。

顽皮狗的版本控制方案

顽皮狗的版本控制方案注重解决数据复制问题，他们采用了自行开发的私有版本控制工具。这套工具使用 UNIX 符号链接，从根本上解决了数据需要复制到本地才能使用的性能问题。在用户未对文件进行 checkout 之前，本地文件只存在符号链接，而一旦进行 checkout 操作，文件会被复制到本地，同时替换原有的符号链接。当文件修改完成后，进行 checkin 操作会将文件更新到版本控制服务器，并且再次用更新后的文件替换本地文件的符号链接。这套版本控制工具在 UNIX 系统上具有很好的功能，但在其他操作系统上需要重新开发。

Epic 使用的版本控制

观察 Epic 在 Github 和 P4 提供的虚幻引擎源码，不难发现两者有如下区别：

P4 仓库不需要 Setup 就可以直接编译，因其拥有完整的文件内容。
P4 附加有 Platforms 代码，包含所有主机平台的源码集成。
P4 仓库附带一个 QAGame。
P4 仓库根目录有 RunUBT、RunUAT 的脚本。
Git 仓库具有独有的 Setup 脚本和 gitignore 文件。

可见，P4 仓库是 Epic 进行核心开发的位置，Epic 内部应该不会采用 Git 作为核心版本控制工具。P4 仓库可以应对大量文件的迁入迁出和改动，如果对引擎改动较多，需要保证上百 GB 文件的版本控制，那么 P4 是唯一之选。

而发布在 Github 的仓库通过挂载非核心第三方依赖代码到外部的方式精简了仓库大小，适合个人和小型开发团队。如果对引擎的修改很小，可以使用这种方式，并且不建议将 Setup 下载的那一大堆文件加入 Git 存储库中。使用 Git 可以保留核心引擎代码的修改，但仅限于小部分的改动，所有开发成员依旧需要下载数十 GB 的 Setup 文件才能运行。

大部分大厂所使用的方案

由于游戏开发和传统软件开发的区别，大型游戏公司基本都采用 P4 作为主要的版本控制系统，并以 Git 或者其它工具做为辅助。虽然 P4 不见得是最好用的版本控制工具，但需要管理许多二进制文件的需求，使得只有采用 P4 才可快速地处理如此庞大的游戏资产及源码组成的仓库。

在使用虚幻引擎的项目中，我们常常会使用一个仓库来管理所有文件，而不是仅仅放置游戏的工程代码和美术资产。这些文件可能有：

项目的策划和其他文档。可能是 Word、PDF、思维导图、Markdown、网页等多种形式。
美术创作的原生资产。比如 Blender、3DS Max、Photoshop 等工具使用的原始文件格式。
一些二进制文件。比如虚幻引擎的 UGS 功能可以为不会编译引擎的人使用最新版本的项目自定义引擎提供方便，但这要求我们在仓库存放一份引擎的二进制文件。
自动化的脚本和相关依赖软件。类似 Ansible、Vagrant 等工具提供的虚拟化环境和自动部署服务器的工作流。

游戏项目是复杂多变的，除了上述需求，可能还有许多文件需要存储在仓库中，以便提高开发效率。

有些项目会使用 Git 和 P4 配合，拆分不同团队的工作流程。比如给美术提供一个 P4 仓库，以便他们追踪和更新最新的美术修改；再为程序提供 Github 或 Gitlab，作为代码的版本控制工具；最后再通过某种工具将其联合起来，保证整个体系的运作。

一些研究

Atlassion 对 Git 的讨论

Atlassian 是游戏开发者非常熟悉的公司，由于其旗下拥有 Bitbucket Cloud 这款产品，还与 Github 一同开发了 Git LFS，这里引入 Atlassian 对 Git 的相关讨论颇有一点王婆卖瓜的味道。但我们依旧可以在文档里发现一些有价值的信息，其中提及的许多问题也将是我们实践时会面对的。

Atlassian 指出，大型存储库变得“大”，一般有两个原因：第一是有非常多的历史提交记录，第二则是仓库中包括大量的二进制文件。

对于过多历史记录的问题，Git 提供了一些帮助我们改善的办法，比如浅层克隆可以只克隆最新的一部分提交，移除大部分历史记录带来的包袱；而 git filter branch 命令也可以帮助我们筛选不需要的旧资产；或者干脆只拉取一个分支。这些方法都能尽可能地削减仓库大小。
而大量二进制文件则是所有游戏开发者都要面对的问题，我们会签入各种贴图、模型、材质文件、蓝图等。对于二进制文件，Git 的处理并不是特别好，我们只能够调整一些压缩相关的设置来减少大型文件对仓库的影响，但这无疑是杯水车薪。同时，其不支持这些二进制文件合并，也不支持锁定文件以避免因多人同时修改单个文件而产生冲突。

Git LFS

Git LFS（大型文件存储）是 Github 和 Atlassian 以及一些社区贡献者开发的 Git 拓展。它通过单独处理大型文件来优化 Git 存储库的速度和空间占用，它会延迟下载大型文件的时机，确保克隆仓库的速度。

Git LFS 通过指针文件来替换大文件，并将大文件存储在本地缓存中。远程存储库将会绑定一个 LFS 存储库，在提交标记为 LFS 的文件时，大文件将会自动存储到绑定的 LFS 存储库中。使用 .gitattributes 文件可以过滤和标记 LFS 文件，并且所有处理都是无缝和自动的，使用者无需关心任何 LFS 拓展的存在。

Atlassian 认为 Git LFS 可以解决游戏开发者的痛点——二进制文件问题，并且强烈呼吁游戏开发者从 P4 切换到 Git 中来。存储库大小的问题，可以使用 Git LFS 轻松解决，而 Atlassian 并没有就文件锁定的协调问题给出合理的解决方案，只是声称“在 Git LFS 路线图中有一种出色的文件锁定功能”。Atlassian 认为，Git 的子模块和子树功能能够替代 P4 可以手动挑选单个文件进行拉取的优势。

我选择了什么方案

分析我的需求：

基于 UE 5.2 进行开发，需要集成引擎源码到仓库，原版引擎 Github 仓库大小约为 1.5 GB；
插件和额外拓展三方库不提交到仓库，使用 Setup.bat 文件来拉取；
插件和第三方代码库可酌情添加到工程中，并不会占用太多空间；

基于前文的研究，在不涉及过多美术资源的情况下，是可以使用 Git LFS 替代 P4 进行版本控制的。开发初期，时间最为宝贵，节约时间可以保证想法的快速迭代和验证。那么，对笔者而言，拉取和提交时的速度、配置和学习成本是最重要的。

首先，我们必须确保完整拉取仓库不会消耗太多时间，因为拉取大型仓库非常容易因网络问题失败。此外，Git 不支持断点续传，而 Git LFS 可以帮助我们缩短仓库拉取的所需时间。
其次是配置简便快速，部署一个 Gitlab 几乎等同于拥有了一大包工具：Codereview、Git 服务器、CI/CD 工具、多用户多仓库管理后台，以及 Slack 等多 App 的集成插件等等。
最终我投向了 Gitlab 的怀抱，它可能不会是我的永久解决方案，但至少可以完美应对我目前的工作流。

基于 Gitlab 实战

如何部署 Gitlab

Gitlab 不仅仅提供一个 Git 服务器，还包含一个类似 Github 一样的网站，供开发者自己使用。根据官方文档，我们可以通过多种方式进行部署：

Linux 安装包：直接安装到系统中，类似平时在 Windows 中双击 exe 直接安装软件。
Helm：在 Kubernetes 集群中部署 Gitlab，这是时下大企业流行的分布式云服务部署方式。
Docker 安装：Docker 是对个人用户非常友好的部署方式，类似在一个虚拟机中运行 Gitlab，我们只需要下载和部署这个“虚拟机”镜像就行。

运行 Gitlab 服务器的推荐配置是 4 核心 CPU + 4GB 内存，可以支持 500 名用户。如果部署在云端，则需要购买该配置以上的云服务器实例。

使用 Docker 部署 Gitlab

这里我们选择 Docker 方式部署。笔者分别尝试了部署在个人 NAS （群辉，4 核-16G）和 Linux 个人 PC （6 核-16G）之上，除了网页的打开速度有些微差距以外，体验并无二致。

安装 Gitlab 的服务器需提前安装 Docker，其安装方法本文不再赘述。以下是部署需要的命令，直接复制粘贴到 Linux 命令行中执行即可：

docker run --detach \
    --hostname gitlab.example.com \
    --publish 443:443 --publish 80:80 --publish 22:22 \
    --name gitlab \
    --restart always \
    --volume ~/gitlab/config:/etc/gitlab \
    --volume ~/gitlab/logs:/var/log/gitlab \
    --volume ~/gitlab/data:/var/opt/gitlab \
    --shm-size 256m \
    registry.gitlab.cn/omnibus/gitlab-jh:latest

gitlab.example.com 是域名，若无也可填写机器的 IP 地址。
443、80 是网页的端口号，22 是通过 SSH 协议拉取仓库的端口。此处的冒号表示我们将容器内部的服务端口号映射到外部的哪个端口，实际访问 Gitlab 时，请使用冒号前的端口号。
--volume 参数可以将数据和日志文件从容器内映射到宿主机上，方便我们备份整个服务器的数据及查阅日志。

经过几分钟的等待，如果没有任何报错，我们就可以顺利地在网页上打开刚刚部署的 Gitlab 网站了！

更具体的安装教程可以参考官方文档：https://docs.gitlab.cn/jh/install/install_methods.html

使用 Gitlab

访问我们部署时填写的 IP 或者域名，来到登陆界面：

初次登录时，用户名为 root，默认密码在文件/etc/gitlab/initial_root_password 中，24 小时后该文件会被自动删除。root 用户登录后，请及时修改密码。

出于篇幅原因，无法逐一列出详尽的 Gitlab 使用教程，不过初次使用时，首先需要做两件事：

新建用户，配置新用户权限管理
新建仓库，尝试在本地使用 HTTP 和 SSH 两种方式拉取

这两件事可以帮助我们诊断 Gitlab 仓库是否工作正常，网络配置是否可用。
此后就可以开始探索 Gitlab 的所有功能了，和 Github 的使用几乎别无二致：

CI/CD 对应 Github Actions，可以自动化编译和测试每一次提交；
Issue 面板可以汇报 Bug，追踪项目的问题；
Integrations 可以配置各种第三方服务的链接，比如 Slack 通知、Jire、Confluence 等等；
Wiki 功能可以基于 Markdown 文件编写项目的文档；
Merge Request 对应 Github Pull Request，可以在浏览器中审查代码，完成代码分支合并。

管理源码版 UE 仓库

笔者尝试了在自部署 Gitlab 中管理基于源码版虚幻引擎的项目，这一小节将分享管理过程和使用体验。

在 Gitlab 管理的虚幻引擎源码仓库

第一步：配置 Git LFS

在拉取代码前，我们首先要配置 Git LFS。关键在于两个文件：.gitattributes 以及 .gitignore。

.gitignore 文件用于过滤一些中间文件和二进制文件，防止其被上传到仓库中。具体可以参考 Epic 官方仓库的 ignore 文件，如果无法打开，则需要加入 Epic 组织才能访问，笔者的第一篇专栏《虚幻引擎应用实例分享（一）：安装 & 编译》有提及相关步骤。下方文件开头额外排除了两个文件夹 Game 以及 Assets，前者是我们的游戏项目文件夹，后者是资源文件夹，后续会单独处理它们。

# Ignore all files by default, but scan all directories
*
!*/
!/Game/**
!/Assets/**

随后是 .gitattributes 文件，这个文件规定了仓库中哪些类型的文件会经由 Git LFS 上传。文件中，每一行代表一种文件类型，通过后缀名进行区别。

# UE file types
*.uasset filter=lfs diff=lfs merge=lfs -text
*.umap filter=lfs diff=lfs merge=lfs -text
*.upack filter=lfs diff=lfs merge=lfs binary
*.ddc filter=lfs diff=lfs merge=lfs binary

由于文件内容过多，笔者直接将自用的版本上传到了 Github，有兴趣的朋友可以按需取用。

Github 地址：https://github.com/Dluckxx/ue-ignore

第二步：拉取代码

首先尝试直接从 Github 拉取引擎源码，再将整个仓库 Push 到 Gitlab。在此过程中遇到了第一个问题，网络不稳会导致大型仓库的 Pull/Push 直接失败。由于源码版本引擎包含众多分支与历史记录，总共有约 15GB 大小，对于国内的网络环境来说，拉取过程相当容易失败。

退而求其次，选择只使用 release 版本的 zip 包，然后自己上传到 Gitlab。由于文件变少了，下载、上传自然都不成问题。经验证，不带历史记录的源码仓库约为 1.3 GB 左右，通过国内家庭宽带从外网拉取（30 Mbps），所需时间在一分钟以内。

第三部：进行开发

上传好仓库后，进行开发基本只需要以下几个步骤：

拉取仓库
运行 Setup.bat 脚本（第一次）
运行 GenerateProjectFiles.bat
进行修改并测试
提交代码

Git 托管的引擎源码不包含许多第三方库和依赖文件，我们还需要运行 Setup.bat 来进行下载。在使用 P4 时，第三方库和依赖文件往往都直接传入仓库，拉取后开箱即用——对 Git 来说，上传这些文件无疑会增加仓库的负担，它们足足有接近 50GB！

此处有个小技巧，修改 Setup.bat 脚本为多线程下载可以极大加快下载速度：

修改脚本支持 64 线程下载

笔者尝试上传过虚幻素材商店的素材包，也尝试了多人协作开发的代码和蓝图提交，表现均良好。除了第一次运行需要一两个小时下载依赖文件，后续开发中并没有过多阻碍效率的情况。

第四步：CI/CD

在游戏开发工作流中，通常需要一个方便的出包方式自动打包版本，以供测试。在程序员的机器上本地打包会影响开发效率，同时，文件存储在本地也不利于分享及团队内协作。我们常常需要一个基于版本管理的打包系统，并可以通过远程界面操作。大型团队一般用 Jenkins 控制面板进行打包，而我们可以使用 Gitlab 的 CI/CD 模块来实现自动化打包。

有了 Gitlab，我们可以实现以下自动化操作：

每当有提交被 Push 到仓库中，就会触发一次源码编译。只有通过了编译的提交才能被合并到 main 分支。
使用 Slack Integration，每次合并请求会推送一条消息到 Slack 频道。一起做游戏的小伙伴可以检查代码，知道项目的更新情况。
用 Gitlab 的 CI Job 来运行打包脚本，支持在网页上一键打包版本，并且拷贝到 NAS 中的对应目录。

要实现如上操作，第一步是配置 Gitlab Runner。这里可以参考官方教程。使用虚幻引擎需要在 Windows 进行编译，因此大致步骤如下：

下载 gitlab-runner.exe，地址：64-位或 32-位；
新建一个文件夹，将 gitlab-runner.exe 放入，并在当前目录运行命令提示符工具。由于 Runner 会拉取仓库，编译代码，因此该文件夹会占用过多空间，请放在一个空间足够的位置。
运行 .\gitlab-runner-windows-amd64.exe register 注册 Runner 到 Gitlab。
运行 .\gitlab-runner.exe install 以及 .\gitlab-runner.exe start

注册时需注意：其中的 token 要在 Admin - CI/CD 面板里获取。

笔者自己在操作中还遇到了一个问题：运行 Job 时日志会显示报错，找不到对应的 shell。如果需要在 Windows 上部署这一套系统，还需要修改 toml 文件中的 pwsh 为 powershell。修改后需使用 .\gitlab-runner.exe restart 命令重启。

配置好 Runner，即运行我们自动化的机器后，下一步就是具体定义我们的自动化脚本任务了。这一步的关键在于一个 yaml 文件（关于 Gitlab 的 CI/CD ，笔者也只使用过一小部分功能，详细的信息和教程请参考官方教程）。

首先分享一下我使用的 gitlab-ci.yaml 文件，我将它放在仓库的根目录下：

stages:
  - setup
  - build
  - package

variables:
  GIT_STRATEGY: fetch
  GIT_CLEAN_FLAGS: none

setup:
  stage: setup
  script:
    - .\Setup.bat
  retry: 2
  tags:
    - windows

build-game:
  stage: build
  variables:
    GIT_STRATEGY: none
  script:
    - echo ".\Engine\Build\BatchFiles\Build.bat GemGame Win64 Development -WaitMutex -FromMsBuild"
    - .\Engine\Build\BatchFiles\Build.bat GemGame Win64 Development -WaitMutex -FromMsBuild
  tags:
    - windows

package-game:
  stage: package
  script:
    - py .\Game\Scripts\package.py
  when: manual
  tags:
    - windows

开头的 stages 分别代表三个阶段：

setup：运行 Setup.bat 脚本下载依赖库等文件
build：编译 C++ 代码
package：打包整个游戏的版本

有了这个配置文件，每一次 Push 代码到仓库都会执行 setup 以及 build 步骤。由于我们设置了 when: manual ，因此 package 不会自动执行，需要去网页上手动点击运行。如果我们在仓库配置中将 main 设置为保护分支，再要求 CI/CD 通过后才能合并代码，就可以确保开发时仓库中的代码不会出现编译错误。

GIT_STRATEGY 与 GIT_CLEAN_FLAGS 的配置意为每次执行这个自动化的时候，都会使用 git fetch 来更新代码到 Runner，并且下次执行时不清空整个缓存文件夹，这是由于 Setup.bat 脚本需要较长时间运行。

最后说一说如何自动化出包。我编写了一个 Python 脚本用于一键式打包，运行 package.py 即可自动在 Runner 的缓存文件夹内出一个包。如果我们拥有一个共享盘，可以使用 SMB 协议将其挂载到 Runner 的一个指定目录，随后在打包的 Archive 阶段将 Archive 目录指定为共享盘即可。我将 Archive 阶段的参数暴露给了 Python 脚本，因此在运行脚本时加上 --archive="Path" 命令行参数即可自动将包存放在一个共享盘目录中，供团队成员使用。

如果是使用别的引擎打包，或者需要自己拷贝文件，也可以在 script 下添加新的命令，或是添加一个新的 Job 来负责执行归档和拷贝任务。由于管线可以高度自定义，我们几乎可以实现任何需求。

总结

无论是 Git 还是 P4，于非局域网环境下搭建的服务器，在管理超过数十 GB 的仓库时都显得捉襟见肘。但相对来说，由于可以“断点续传” ， P4 的体验更好一些。不过，当整个仓库大小达到一定量级时，请务必在本地局域网环境进行部署，不要挑战家用带宽的上传速度。另外，对于有 CI/CD 和协作需求的独立团队，使用 Gitlab 是最为简便的，因为 P4 只提供一个仓库的基本功能，代码审核等功能都需要以 Web 服务的方式单独部署。

为项目考虑版本控制方案时，最重要的还是整理当前的需求。在 DevOps 领域并不存在所谓银弹，随着需求愈加复杂，我们在整个系统中自定义的部分甚至会超过工具本身，单纯的效仿很可能会陷入折腾的死循环中。游戏开发领域的新手不妨从 Git + LFS 开始上手，根据项目需要，再逐步考虑加入一些自动化流水线和脚本作为效率工具。随着实践经验的提升，工具的优劣就不再是需要纠结的问题。