前言

本篇作为 GMS 中文教程系列的特别篇放出，来和大家聊聊版本管理的问题。

我相信有很多刚开始做独立游戏的人不用版本管理（VCS），因为我自己常常也懒得用。但如果你是认真的想要做出点什么像样的东西，很难想象你能不通过版本管理而完成这一切。比如看看以下这些场景：

1. 你想尝试一个新的功能，结果发现把整个游戏搞砸了，这时你是否想要直接回滚到上一个能让游戏正常运行的版本？如果没有这样回滚的功能，也许你根本就不敢尝试有风险性的改动？
2. 你和你的团队远程合作（这种情况在独立游戏里很常见），如何共享内容给彼此呢？曾经我合作的一次是双方互相发送邮件附件来传送项目文件……直到项目文件超过了25M（Gmail的附件大小限制）。更不用说多方同时对一个文件进行修改时的冲突管理了。
3. 你是否会在多个地点或者设备制作你的游戏，例如家里的台式机以及外出时的笔记本？
4. 你是否会为不同的场合交付不同的游戏版本？例如为独立游戏节提交的参赛版需要是一个稳定的版本，而给帮你测试的小伙伴们的是包含最新内容的版本。
5. 当帮你测试的小伙伴告诉你bug出现的时候，你要如何迅速知道是哪里的改动导致了这个 bug？
6. 当游戏发布以后每次版本更新时，你要告诉玩家此次更新所包含的内容，你如何得到确切的改动列表？

上面所提到的这些情形，都可以通过版本管理来得到很好的解决。所以，今天我会介绍如何用 GitHub 提供的免费 git 仓库以及 GitHub Desktop 客户端来对你的 GameMaker:Studio 游戏项目进行版本管理。当然，其实这个版本管理的过程与 GMS 完全无关，即使你以后用 Unity 或者别的引擎来开发游戏也同样适用。

GitHub 注册

GitHub 是一个通过 Git 进行版本控制的软件源代码托管服务，这个 GMS 系列教程之前的所有项目资源均存放在 GitHub上。

它提供 1G 的免费公开代码仓库，公开代码仓库的意思是任何人都可以看到你的项目文件，如果需要无限量的空间或私有代码仓库，则需要升级到付费账户。与 GitHub 类似，但可以提供免费的私有代码仓库的网站有 GitLab.com 和 Bitbucket.org，所以如果你很介意不希望你的项目公开的话，可以选择这两个地方。

首先你需要注册一个 Github 账号，这个过程相当简单，首先在 github.com 的首页上的注册区填入你想要起的用户名、邮箱和密码，然后点击 Sign up for GitHub 注册即可。点击进去后会让你选择是免费的公开仓库还是付费的私有仓库，默认是免费账户，所以点 Continue 继续下一步就好。然后到了第三步会让你填写一些个人信息，不过这些都是可以跳过的，直接点 Submit 提交就完成了注册。你会看到下面这个欢迎页面：

同时你所填入的邮箱也会收到一封验证邮件，点击邮件内的链接验证你的邮箱有效即可。
建立代码仓库
点击 Start a project（新建项目）来到建立代码仓库的页面，你所要填写的仅仅是你的代码仓库名称（Repository name）：

例如我这里新建了一个叫做 GMS_Repository 的仓库，然后点击左下角的 Create repository（新建仓库）就完成了创建过程。这时就来到了你的代码仓库的首页，这里显示了你的git访问地址和一些操作的命令行简介：

这个地址以及你的用户名密码等信息会在使用第三方工具访问 GitHub 时用到。

以上步骤完成后，还需要配置 SSH 公钥。它来为用户提供提交代码的身份认证。这一步需要用到简单的命令行操作，按部就班如下面的指南操作即可。

安装GitHub Desktop

本来这里是打算介绍使用 SourceTree 这个工具的，但后来看了一下它的注册过程需要翻墙，所以本着尽量方便的原则，就用 GitHub 的官方工具 GitHub Desktop 来演示好了。其实一旦熟悉了版本管理的概念后，任何工具都是类似的，或者有人会更喜欢用命令行的方式来操作。

点击上图中代码仓库首页的 Set up in Desktop（设置桌面）就会跳转到GitHub Desktop的下载页面。下载安装过程一路确定就好，在安装成功的欢迎页面会有三个步骤（如下图），分别是登录、配置、仓库，首先在登录页面会需要你用之前注册的 GitHub 账号登录：

在配置页面使用默认的设置继续下一步，在最后的仓库选择页面，如果你之前没有配置过任何 git 仓库的话，应该是看到以下的空白信息，选择 Skip 跳过就好。

最后就来到了GitHub Desktop的主界面：

GitHub Desktop实践

Git 是一个很强大的分布式版本管理系统，但正因为如此强大灵活，以致与我刚从 svn 这样的集中式版本管理切换过来的时候都晕了好一阵。所以不如我们直接通过对工具的使用来熟悉 Git 的各个概念。

一、克隆（Clone）

你应该还记得在 GitHub 注册那一节内容里，我们在 GitHub 网站上创建了一个叫做 GMS_Repository 的仓库，这个仓库是存在于网站上的，叫做远程仓库（Remote Repository），我们要做的第一件事是将这个远程仓库克隆到本地，有了 GitHub Desktop 的支持，这个操作非常简单：

在点击左上角的+号并选择 Clone 后，它会列出你在 GitHub 网站上已有的仓库，选择我的仓库 GMS_Repository 并确定后，再选择一个本地的目录，就会将远程仓库克隆到本地。
因为我们这时仓库里没有任何内容，所以只是会克隆到一个空的本地目录，但假设我们的游戏开发到一半的时候，团队增加了一个新的成员。那么此时他在克隆项目仓库时，将会得到所有远程仓库中已有的游戏内容。
而那个我们将远程仓库克隆到的本地目录，在上面的动图演示中，就是我桌面上的“GMSFolder”目录，被称为工作目录。我们在本地创建和修改游戏项目，是在这个目录中进行的。

二、本地改动（Local Changes）

现在，在 GitHub Desktop 显示的本地仓库下面，还没有任何改动，这个页面是这样的：

接下来我们用 GMS 来在这个目录中新建一个项目，我把这个项目的名字叫做 GitHubSample，建立后保存一下，再回到 GitHub Desktop 工具，稍等一下工具的刷新，就会看到所有 GMS 新建的项目文件都已经被显示在了改动列表当中：

上图中那些打勾的文件即为 git 所检查出来发生改动的文件，而右边绿色的+号表示这些文件是新加入的文件。

三、提交改动（Commit）

在上图的的改动列表下面就是提交改动的地方，分别是所要提交改动的概要和描述，其中改动概要是必填项，填好以后就可以提交你的改动了。

这里所谓的“提交改动”是指让本地的git版本管理系统能够记录你的版本信息。举例说，假如现在我去这个项目的本地目录 GitHubSample。gmx 里将 GMS 所生成的项目文件全部删除掉，我依然可以在 GitHub Desktop 中通过 Discard changes（撤销改动）命令来把这些文件恢复回来，这就说明了本地的git仓库中保留了这些文件的信息。
但如果我们把本地的git仓库删除掉，那么这些文件的版本信息就丢失了，因此我们需要把本地的版本改动推送到GitHub的远程仓库中。

四、推送改动（Push）

推送改动的意思是指将本地已经记录下来的版本改动（对我们来说是新建了一个GMS项目），也同样的应用到你在GitHub的远程仓库（也就是说GitHub也保存一份你新建的这些项目文件）。
推送的操作在GitHub Desktop中叫做Publish，我们将GitHub Desktop页面切换至History栏，左边这里会显示之前提交的本地改动：

点击右上角的Publish按钮，即开始了将推送的操作，这一步根据网络状况会持续数秒左右，等到那个转动的图片停止下来的时候即完成推送。这时候我们再登录GitHub网站查看，就会看到改动已经在远程仓库里了：

那么在这个时候，即使你删除掉本地仓库或者是你换了另一台电脑，你都可以通过再次克隆（Clone）这个远程仓库到本地来重新获取项目文件。

五、拉取改动（Pull）

如果这是你的个人项目，那么你的工作流程应该是这样：对每一个新添的游戏内容或者功能，首先在本地修改实现，然后提交改动到本地仓库，最后推送改动到远程仓库。但如果是多人的远程合作，那么每个人都会将自己的改动推送到远程仓库，如果你想要获取别人的改动（你应该总是尽可能的及时获取其他人的改动，以避免修改冲突），这时你需要去做一个拉取（Pull）的操作。
这里我们通过直接在GitHub网站上对远程仓库操作来演示。先登录GitHub，进入你的仓库后，可以通过网页直接进行文件的添加、修改或删除等操作。我们以添加文件为例：

红色框那里的按钮可以在当前目录新建一个文件，点击后进入文本编辑页面：

这里我新建了一个Test.txt文件，并随便填入了一些测试文本。在这个页面的下方点击绿色的Commit new file（提交新文件）按钮即可完成提交。完成后，就可以在仓库的首页看到这个新加的文件了。

然后我们回到本地的GitHub Desktop客户端，在这里Pull操作是通过一个标签为Sync的按钮完成（这个Sync按钮和之前提交改动时的Publish按钮其实是同一个，根据当前仓库状态的不同而显示不同内容）：

数秒后等待操作完成，即可看到在改动列表里显示了我们之前在GitHub网页上提交的新文件：
同时在文件目录中也可以发现这个新的 Test.txt 已经更新至本地了。

六、合并改动（Merge）

在远程合作时，多方常常需要同时对项目进行修改。当相互之间改动的文件没有重叠时，这些改动的合并是非常简单的。而如果两方同时修改了一个文件，情况就会稍微复杂一些，因为这需要你去手动解决双方的改动冲突（Resolve conflicts）。这里我们来演示一下这样的情形。
我们首先来在本地进行一些改动：

1. 修改Test.txt

   在之前文本的下方再加入三行文本：

   This is line 1.
   This is line 2.
   This is line 3.	
   

2. 新建一个FileA.txt

完成后 GitHub Desktop 会自动检测到这两处改动：

注意左边红色标注的这里表示这两个文件的改动，一个是添加的新文件，一个是修改文件内容。上方红色标注这里是每当 GitHub Desktop 检测到本地改动时，Change 标签上会显示一个小圆点。
接下来我们按照之前说过的步骤，给这个改动的概要填写为“本地的第一次改动”，然后将改动提交到本地。
此时，我们先不要将改动推送至远程仓库，而是在 GitHub 网站上进行另一项改动来模拟多人合作时的情形：

1. 修改Test.txt
   在之前文本的下方再加入四行文本：

   This is line 1.
   This is not line 2.
   This is line 3.
   This is line 4.	
   

这里我们特意将远程的修改与本地修改的内容不同。

在GitHub上修改文件的操作是先点击Test.txt文件，进入到这个页面后点击右上的编辑按钮：

将新的内容粘贴之后点击下方的绿色按钮将改动提交至远程仓库。

此时本地和远程仓库的改动列表就存在了差异，这是本地的历史记录：

这个是远程的改动记录：

这个时候，假设我作为进行了本地改动的人，想要将我的改动提交到远程仓库，我会去做推送的操作，于是去点击那个Sync按钮，结果就会遇到同步冲突的提示：

当你确认后，此时的改动列表里会显示Test.txt这个文件存在冲突

于是接下来需要我们去手动如果解决冲突的内容，点击右键选择打开文件或者直接在目录中打开Test.txt文件均可。其中：

<<<<<<< HEAD
This is line 2.
This is line 3.
=======	

这部分是显示的本地的改动，而下面这一半显示的是远程的改动：

=======
This is not line 2.
This is line 3.
This is line 4.
>>>>>>> origin/master	

值得注意的是，虽然版本管理能帮我们很大的忙，甚至有的版本管理工具能够一定程度的自动解决冲突。但最好的避免冲突的办法还是尽量在人员划分上清晰设置每个人的工作内容，在项目结构上不要将不相关的内容放置在同一处地方。原因是：

• 只有文本文件（代码文件）能够进行冲突合并，而对于图片、二进制数据文件等，就只能二选一选择继续使用本地的改动或者远程的改动了。
• 就算是自动解决冲突的方案，本质上也只是通过文本的匹配来识别双方修改中共同的部分（例如上面那个改动例子里的This is line 3.）、一方新增的部分（如This is line 4.）等基本情形。而如果双方的改动涉及复杂的逻辑，这个过程通常就只能手动进行，这需要对双方的代码逻辑都十分清楚才能完成。

对于我们示例中的情况，我们只需用文本编辑器打开Test.txt后，修改成以下内容即可：

This is line 1.
This is line 2.
This is line 3.
This is line 4.

然后在GitHub Desktop中提交这个改动后再次推送，这次就应该能够成功进行了。这时再到GitHub网站上去查看远程仓库，就能够看到“本地的第一次改动”和刚才解决冲突的改动都已经存在了：

附录

以上介绍这些内容能够让你初步使用 git 进行版本管理了，但是，如果希望深入了解更全面的内容，还远远不够。

这里再提供一些入门资料供大家进一步参考：

• 一篇非常细致的图文并茂的入门教程（有助于理解原理和机制）。
• 来自巴哈姆特的游戏开发版本管理教程（有助于梳理具体步骤，可以配合本文来看）。