游戏项目的分支管理实践

前言

对于一个多人协作项目来说,没有分支管理我真的没法想象有多混乱了,代码、美术资源、配置表格都需要通过合理的方式提交到仓库,便于代码review、测试、持续集成、资源管理等。

1. 代码仓库的选择

我们常用的就是SVN、Git、p4等,这些工具都一直在升级和优化,因此在项目一开始的时候最好考虑清楚,项目进行到一段时期后,要修改就很难了,一方面是团队已经习惯了,哪怕有各种问题也会选择忍受;另外就是历史记录的迁移带来的兼容性问题;还有就是相关配套的工具也要修改,比如持续集成(CI)。

我所在的团队也曾在工具遇到问题时,寻求其他工具能否解决,结果多次对比下来还是p4+SVN/Git方式对于大型游戏项目来说比较实用(就目前的评估来看)。也就是客户端、美术、策划等用p4,服务器用SVN或者Git。这个模式我了解过一些项目,包括原神、天涯明月刀、PUBG、王者荣耀新项目都是用这个组合,区别只是服务器选择SVN还是Git。

为什么选择这个组合?

界面友好性:p4的操作界面对于非程序员来说,要容易理解得多,虽然Git和SVN也有很多GUI,但是缺乏标准和一致性,每家都有各自的特色,尤其是Git,本身的分布式存储模式从理解上就是一种门槛。

安全性:对于游戏项目来说,研发成本很高,为了防止一人离职,源码全带走的问题,将客户端和服务器代码分开管理,可以有效避免这种情况。此外p4的权限管理可以精细化到每一个文件和目录,可以分组、通配符目录等,这样可以很灵活的管理权限。

大文件支持:p4对于拉取大量文件的稳定性相对来说比较高,而且是集中管理,大家可以只下载需要的文件,不同于Git分布式需要全部拉下来(虽然现在也可以配置),一个动辄100G的分支,没有多少人能忍受。

具体可以参考一下p4自己的对比文章:Perforce vs SVN

2. 动态分支还是静态分支?

Git的设计思路是有一个需求或者修改,就创建一个分支来完成,确认没有问题后再提交主线(master),这样做的优势是灵活、解耦、互不影响。对于资源量少、依赖关系简单、团队成员协作少的项目比较合适。

对于资源庞大、第一次资源编译时间很长(Unity和UE4都有这个问题)的项目,频繁的创建和销毁分支本身就是一种巨大的成本,也不利于权限管理,给持续集成也带来很大的挑战。因此大型游戏项目选择静态分支会更合适一些。

3. 分支定义

(图中实线箭头表示复制(Clone)全部分支内容到另一个分支,虚线表示合并(Merge)新内容到另一个分支)

分支名称和定义:

Master: 主干分支,所有开发内容的最全集合,除了branches上的内容暂时不在。

Feature branches: 特性分支,对于一些跨发布计划、提交对master稳定性影响比较大的内容,从master拉(clone)分支开发,完成开发并验收后,提交master。

Pre-release: 预发布分支,用于阶段性演示、玩家调研、测试、上线后灰度发布等。需求都在master分支开发,等一个阶段内容基本完成后,clone到pre-release分支,然后在pre-release分支上稳定版本,同时避免master新特性开发对pre-release分支的影响。

Release: 发布分支,用于对用户发布或更新的分支。在Pre-release发布确认没有问题后,从Pre-release拉到Release用于最终版本发布的准备。Pre-release可能会进行1-2周的问题修复,因此改动量还是比较大,而Release一般只有2-3天用于处理最严重的问题,因此提交内容应该极少。

Hotfixes: 紧急分支,用于线上紧急问题处理。

提交原则

这个图从左向右看,提交右侧分支的内容,需要同时提交它左侧的所有分支。对于一次内容提交,如果需要提交Pre-release分支,那么你需要先提交Master,然后使用merge方式提交Pre-release。

原则就是:从左至右提交。

4. 实际案例

假设我们项目现在开始进行发布计划A的开发,开发内容(示例)如下:

其中第3项"主城美术效果升级"因为场景修改内容多,会造成剧情任务、功能NPC等变化,影响面比较大,因此我们拉分支Branch1来进行开发,等场景稳定后,再提交到Master。

而其他内容,都在Master分支上开发,直到所有内容都完成开发,并进行了初步验收。验收后,将Master上的资源拉到Pre-release上,进行优化和缺陷修复。此时的Master可以开始下一个发布计划的内容开发了。

Pre-release经过1-2周优化稳定后,对外灰度发布,灰度期间有问题还可以通过Pre-release分支进行修复,直到可以进行全量发布。在正式发布之前,将Pre-release拉到Release分支进行发布,发布到线上后,将Release拉到Hotfixes分支,以备线上有紧急问题需要更新,而Release分支则作为下一次发布使用。

5. 大版本、周更新和紧急问题的处理

大版本一般是以4-12周为单位的更新,内容比较多,需要更多的时间(1-2周)进行灰度来稳定版本,有两个做法可以参考:

方案一:暂停周更新

大版本灰度期间暂停一次周更新。这样Pre-release分支可以用来稳定大版本,时间也够。一般有大版本,那么周更新会是一些常规性的小内容更新,因此可以提前规划,在大版本发布前2周统一处理,实在不行还可以用Hotfixes分支来发布内容。

方案二:分离更新通道

Pre-release分支作为大版本预发布分支,周更新直接使用Release发布。这样做会存在Release直接发布的问题,但是可以保证周更新节奏。

6. 多分支提交成本考量

从上面的情况看,开发人员存在多分支合入的情况。从我带的项目实际情况来看:

80% 的内容只需要提交Master即可
18% 的内容需要提交Master和Pre-release分支
只有很少的严重缺陷,会需要同时提交三分支(Master + Pre-release + Release)
需要提交四分支的情况,一年也难有2次(如果多,说明质量控制实在太差了,经常修复线上问题)

加上无论提交几条分支,都是同时操作,避免了忘记提交的问题。

7. 每日转测版本质量控制

很多项目都采用每日转测版本,当然也有周转测试的。显然日转测试因为将版本构建和提交出错的问题切分到每一天,从而能更早地暴露问题,从总体看,版本的质量会更高。

但是每天转测,对于一个100+人的团队,一天提交内容几百条,难免有错误,然后让编译出来的游戏无法正常运行,或者直接编译报错。针对这个问题我们尝试过两种方案:

方案一:关闭提交权限

开始构建版本时关闭提交权限(得益于p4便捷的权限管理,也可以自动化),如果出错,要求开发人员迅速修复后再次构建,直到版本没有问题。过程中其他人员无法提交内容。

这样做会有一点影响开发效率,因为每天可能都会有一段时间开发人员无法提交内容。而如何尽量减少这个无法提交的时间,有几个办法:

提前规划影响面比较大的内容:提前、集中提交
提高构建版本的速度(我们项目最开始构建一次需要2小时,经过优化到30分钟一次,将易出错的内容前置等,可以尽快发现问题)
定时构建,每小时构建一次,提前发现提交内容的出错

方案二:Daily-build分支(推荐)

创建一个分支:Daily-build,专门用于每日转测试构建。然后写一个脚本,每天定时从Master上将当天提交的内容自动merge到Daily-build,然后构建。如果出错,要求开发人员在Daily-build和Master同时修复。

这个方法虽然会多一个专门的分支,但是可以解决前者因权限关闭造成的所有开发人员无法提交的问题,我个人推荐项目尝试这个方案(我也是从PUBG项目那里了解到的)。

总结

合理的分支管理策略是大型项目成功的关键之一。根据项目规模和团队特点,选择合适的工具和分支模型,能够显著提升开发效率和版本质量。关键是:

工具选择要提前规划,后期迁移成本很高
静态分支更适合大型游戏项目
从左至右提交的原则要严格执行
每日构建配合Daily-build分支能有效保证版本质量
多分支提交的实际成本并不高,大部分情况只需要提交Master

这些实践来自于多个大型游戏项目的经验总结,希望对你的项目有所帮助。