本
文
摘
要
2019年7月到2022年2月，这两年半一直在参与开发一款3A游戏，游戏使用UE4引擎开发，我刚刚进去的时候40人左右，离开时200人左右。这篇文章从游戏客户端的角度谈谈对3A游戏大型团队的一些开发心得，先从代码提交、版本管理开始。
痛苦的版本开发：
最开始时，策划和美术使用svn提交修改，主要是content仓库，他们每天直接使用编译好的编辑器。客户端则使用git提交代码，主要是source仓库。
之所以这样是因为策划和美术对svn比较认同，使用容易，提交修改就是一拉一推完事。
程序这边使用git主要是版本比较好管理，各种分支拉起来容易。
但使用这种开发有两个比较大的问题，一个是版本的分支管理非常痛苦，二个是content仓库和source仓库不同步的问题，不仅开发效率低，而且动不动各种崩溃。
解决方案：
策划、美术、程序统一使用git，各种特性功能的开发统统拉分支，最终将分支上的功能合入到trunk分支。
这样做也会带来两个问题，一个是UE4引擎切换分支太痛苦了，每次切换分支基本都要重新编译一次，二个是trunk上依然各种崩溃，虽然相较之前有所缓解，但200个人开发，trunk依然每天各种不稳定。
解决第一个问题需要多环境开发，每个人拉多个工程环境，尽量保证有一个环境是trunk，这样trunk上有问题可以第一时间解决，而且更新trunk的同时可以继续在另一个环境的工程中开发。团队的电脑配置尽量搞好一些，多搞些固态硬盘、内存条等等，有条件把CPU提高一些最好，可以节省大量开发时间，而且也不是很贵。
解决第二个问题比较麻烦，由于我们已经是全员使用git开发了，一些大的特性功能已经是拉分支开发了，而且通常只有合入到trunk的时候会造成trunk不稳定，这点大家基本可以接受，无非就是在别人合线的时候不更新和提交代码。
这样做，如果是小团队可能没什么问题，trunk上有什么问题可以及时解，但在大团队依然会出现比较多的问题，因为总有人直接往trunk上提交更改，200个人，每个人一年出一次大问题，那就代表trunk上天天出大问题。要避免这个问题，就需要严格限制trunk的提交，但每一个提交都拉分支验证肯定是不现实的，效率太低。直接提交trunk的话，又很容易出问题，哪怕是我这种富有经验的 *** ，提交UE4的C++代码也会出现各种平台、崩溃问题。所以处理这种trunk不稳定的问题，我总结了四点：
1.C++代码一律不许直接往trunk上提交，必须拉分支打真机包验证，UE4引擎的C++都是血泪坑。
2.业务系统需要分级，比如登陆模块的代码禁止直接往trunk上提交，必须拉分支打包验证，否则出个小问题无法进游戏的话，就是200个人等你改bug。一些不卡流程副本玩法模块，如果都是lua，可以往trunk上提交，这样就算出问题也就一个不卡流程的模块有问题，你偷偷摸摸的改了，也许别人还不知道。
3.引擎代码有修改提交的话，尽量通知其他客户端同学，让别人中午吃饭或晚上更新、编译trunk。
4.提升策划和美术同学的电脑配置，保证他们在往trunk上提交修改时，尽量本地验证一下。有些策划和美术同学提交修改不喜欢本地验证，主要是他们的机器太卡了，更新一次2个多小时。
往trunk上提交代码，要遵循“宁停三分，不抢一秒”的基本原则，能不交就不交，实在不行的话，最好遵循上面四点。另外由于项目人数短期膨胀过快，不建议新人直接往trunk上提交任何东西。
所以总结下来就是两步，第一步大的特性功能拉分支开发，第二步小的功能或bug修改需要直接提交trunk的话，需严格遵循上面四点。
按照以上方法，2021年这一整年，在trunk上，我一次编译、崩溃、卡流程的问题都没出过。另外还有一点非常重要，由于我们整个工程分成了多个仓库，早期经常出现因仓库不同步而造成的一些bug，此类bug难查且毫无意义。解决方法就是提供一键更新所有仓库的功能，只要出现奇怪的bug，先一键拉新再说，如果还有问题则通知相应同学第一时间解决。
