多人合作怎么传文件？教你用git同步开发【git与游戏开发01】

UP主: Reality_Game · 时长: 11:31 · 🔗 B站原视频

发布: 2024-08-06 · 收录: 2025-06-10

标签: Git · 版本控制 · 游戏开发 · 多人协作 · 程序员工具

用 QQ 群文件协作的常见坑

想象这么个情况：你和几个小伙伴组成了一个游戏开发小团队，你们决定使用 QQ 群传文件和交代需求。很快你们就会发现这种方式有一些难以解决的问题。

首先是操作比较繁琐。用群传文件，你需要先找出你修改后的文件，将其上传至群文件，让团队的其他成员下载。同时你还得不时留意群文件里有没有其他人传的新文件，将其下载并移动到你的工作目录里，如此往复。开发时间久了，处理的文件多起来，操作上只会越来越麻烦。

此外，找出你修改过的文件这一步也很容易出差错。有时你做一个效果会修改很多文件，很容易漏发一两个文件。更有时候你改了一点东西，游戏引擎编辑器会连带着修改其他一些文件，你很难意识到。

群文件可以加文件、改文件，但没法统一地删除文件。你只能在群里 @全体成员，让大伙自行去删除。

开发的时候也可能会有两个人同时修改同一文件的情况。比如有两个人同时拿着第 11 版的 Player 作修改，各自修改并先后上传。如果不特别留意，团队成员很可能就以最新上传的 Player 文件为准，相当于有一个人的工作白做了。

此外还有目录结构不清晰、文件名带序号等问题。

为什么要用 Git（以及客户端选择）

为了解决上述问题，这里就要介绍 Git。其实解决方案并不只有 Git 一种，还有 Subversion、Perforce 等等，只是本系列教程会介绍 Git。

当你去网上搜 Git 的时候，你大概率会找到官网页面。这确实没找错，但 Git 是用命令行来操作的，可能不太好上手。好在 Git 有很多第三方客户端，其中不少都有好用便捷的图形化界面，比如 GitHub Desktop、GitKraken、Fork、UGit、TortoiseGit 和 Sourcetree 等。

出于各方面的考虑，本系列教程以 UGit 作为使用案例，但 Git 的用法不局限于这一个软件，你也可以使用你自己喜欢的 Git 客户端。

提交与历史：Git 里的“存档”

怎么使用 Git？先打个比方：我们玩游戏的时候，一些游戏允许我们存档，通常会在打过一个关卡、打完某个阶段，或做完某件事就存一个档。

Git 里也有类似的概念。比如我做完一个新功能、修了一个错误、重写了一个模块，我就可以每做完一件事存一个档。这个“存档”在 Git 里称之为「提交」。

由这一个个提交组合起来的时间线，在 Git 里称之为「历史」。

提交记录的是对文件的更改。对文件的更改无非就三种情况：新增、删除、修改。其中修改也可以理解为删掉旧有的文件，增添新的文件。

需要注意的是：每个提交记录的是被更改的文件，而不是工作目录的所有文件。

工作目录与暂存区：怎么创建提交

如何创建提交？

首先 Git 会检测你工作目录下有哪些文件有更改。工作目录就是 Git 在跟踪的目录。另外还有一个概念叫「暂存区」，暂存区是用来临时记录待提交的更改的地方。

比如我这里工作区有很多更改，我可以挑一部分更改来打成一个提交，然后为这个提交命个名，就可以提交了，这个提交就会被送入历史。

工作区里还剩下的更改，也可以单独再打一个提交，同样命个名，再送入历史。

HEAD 与检出：读档与时间穿越

再讲讲这个 HEAD 是啥。简单来说，HEAD 的作用是指示当前所在的提交。

先说「检出」的概念，你可以理解为读档。我们存了那么多个档，有时想读档读回去，比如我想读到上一个档，那我就检出到上一个提交。我们会看到 HEAD 移动到这个提交上，这说明工作目录下的所有文件都已经还原到这个提交所在的版本。

打个比方就是时间穿越：你可以把工作目录下的所有文件还原到任意一个时间点。这也是为什么 Git 被称为版本管理系统——可以把文件还原到任何提交的版本，方便回溯。

分支：多人协作最重要的概念

版本管理跟多人合作有什么关系？这里就要介绍 Git 里最重要的概念：分支。

如果你玩过有剧情分支的游戏，比如《底特律：变人》，玩家可以在部分剧情里做出不同选择，不同选择会导致不同的剧情走向，触发不同的事件与结局。Git 里也有分支概念，你可以理解为平行时间线。

通常来说，创建的第一条分支是 master 分支，也就是主分支。分支名字其实可以随便写，你想叫什么都行。比如我新建一条名为 damage 的分支，用来专门处理伤害系统。

我们分别在两条分支上创建不同的提交，两条分支平行进行，互不干扰。在 master 分支上，伤害系统仍然是旧的，因为「重写伤害系统」这个提交在 damage 分支上，不属于 master 分支。

同样的，如果我们检出到 damage 分支，就不会看到 master 新增的预制体，也看不到修改后的关卡。

分支的好处是每条分支的工作互不干扰，只需专注做好这条分支的工作，不用担心影响别人的工作，或者被别人的工作影响。前提是留意 HEAD 的位置：HEAD 在哪个分支，就会把提交送到哪个分支上。请确保你在正确的分支上工作，不然可能会有点麻烦。

合并分支与冲突：怎么把工作合到一起

两条分支的工作最终是要合并的。合并分支通常需要处理一些文件冲突。

比如把 damage 分支合到 master 上，如果两条分支都更改了同一个文件，并且改的是同一个地方，Git 会检测到这些冲突文件。我们需要处理完冲突才能继续合并。

Git 会给三个选项：从两个分支版本的文件二选一，或者自定义解决方案。比如可能找到一个方法可以同时保留两分支的工作：一条分支的二进制掩码设置为 01，另一条分支是 10，那就可以改成 11 来同时开启两位掩码。这只是个例子，自定义方案需要根据实际情况妥善处理。

如果顺利的话，合并也可能不会有冲突。比如两条分支分别更改的是不同文件，就可以顺利合并。还有一种情况是两分支都修改了同一份文本文件，但改的不是同一行，这种情况也不会有冲突。

不过需要注意：即使合并无冲突，也不代表完全没问题。比如一条分支为某个函数增加了一个参数，而且没默认值；另一条分支新写了一个调用，但调用的是旧函数。合并之后虽然没有冲突，但编译肯定会报错。因此合并完最好再检查一下，确保没有问题。

被合并的分支会怎样：删除分支会不会丢提交

可以看到 master 合并 damage 分支后，damage 还是留在原来的提交上没有动。此时如果 damage 再进行提交，会发现新的提交仍然在单独的分支上，因为被合并的分支不会受到影响。master 分支只是把 damage 的工作合了进来，并没有影响 damage 分支。

同样的，master 分支也看不到 damage 现在这个新提交的更改。

如果我认为伤害系统已经重写完了，damage 分支完成使命，想把这个分支删了，这条分支上的提交会连带被删掉吗？不全会。因为 master 分支已经把 damage 的部分提交合并到自己的分支里，换句话说，这些提交也属于 master 分支，所以不会被删除。不属于任何分支的提交默认会被隐藏，并在一段时间后被清理。

仓库、本地与远程：怎么实现“多人联机”

讲完分支，最后讲讲怎么和别人“多人联机”。

先了解「仓库」这个概念。比如我想让 Git 跟踪 MyProject 这个目录，那我就用 Git 在这创建一个仓库。仓库下所有的文件都是仓库中的物品。工作目录下会多一个名为 .git 的隐藏文件夹，这里记录的是仓库相关的数据，这个文件夹不要删，不然仓库就没用了。

这是本地仓库，意思是仓库存在于我们自己的设备上。团队里每个成员都有自己的设备，也都有自己的本地仓库。不同人的本地仓库之间需要同步，是通过「远程仓库」来间接联系的。

远程仓库可以理解为网盘类似的东西。每个成员都往远程仓库上传和下载，由此实现同步开发。现在网上有不少远程仓库托管平台，比如 GitHub、gitee、GitLab、Coding 等，选择你喜欢的即可。

远程仓库的创建与成员加入

首先需要从团队里挑出一人来创建远程仓库，所有成员连接这个远程仓库。

第一步创建远程仓库，前提是你注册了托管平台账号。创建完远程仓库并配置好必要选项后，下一步邀请团队成员作为该远程仓库的合作者，合作者也需要有该平台账号。

本地仓库推送到远程（创建者流程）

在你的设备上使用 Git 客户端创建本地仓库，并创建必要的提交，至少要有一个。

要让本地仓库连接到远程仓库，需要为本地仓库配置远程仓库地址。通常在远程仓库页面上会有很显眼的按钮来复制远程仓库地址。地址分为 HTTPS 和 SSH 两种，这里为了方便直接用 HTTPS。有需要用 SSH 的可以自行研究。

配置完地址后，就可以将本地仓库推送至远程仓库。如果推送时弹出对话框说身份验证失败，就输入托管平台账号密码并重新推送。

合作者克隆仓库（加入者流程）

如果你是合作者，步骤简单一些：注册账号、接受合作邀请，然后复制远程仓库地址（仍以 HTTPS 为例），在自己的设备上使用 Git 客户端将远程仓库克隆为本地仓库。

同样的，如果弹出身份验证对话框，就输入托管平台账号密码并重试。到这里每位成员都可以开始工作了。

多人协作的分支策略与 origin

可以让每位成员单独创建自己的分支进行工作，也可以每个模块创建一条分支，或者直接让所有人在同一条分支上工作。用适合自己团队的设计方案即可。

以 origin 开头的是远程分支。origin 是约定俗成的远程仓库名称，也可以改叫其他名字。

推送、获取与拉取：远程领先/落后的处理

假如我们在本地 master 分支上创建了几个提交，会发现远程 master 分支落后于本地分支。这时需要手动把本地分支推送至远程仓库，远程分支就会同步上来。

需要注意：仅当远程分支落后于本地分支时，Git 才能安全推送。

远程分支也可能先于本地分支，通常见于多个人在同一条分支上工作：别人同步了他的提交，使得我的本地分支落后。这时可以使用「获取」来手动更新远程分支的情况。获取不会改变 HEAD 的位置，不用担心本地工作受到影响。

更糟一点的是：我本地分支上也有自己的提交。这种时候可以用之前提到的合并分支来处理，因为远程分支也是分支。

或者不需要先获取，直接用「拉取」。拉取就是获取与合并两个命令合成一个命令。合并完远程分支与本地分支后，再推送上去。

收尾

以上就是 Git 的基础内容。进阶操作、撤回、实际演示等，留到后面再讲。实际上我跳过了很多概念，并使用了不少不准确的解释，有兴趣的观众可以自行再深入了解 Git。

希望这期教程能帮助到各位开发者。这里是 VIC，我们下期见。