游戏开发团队的Git工作流设计

如果只用一句话来概括为什么要需要定义工作流,那我的回答是”提高效率“。简单说工作流就是定义清楚”什么情况做什么事情,以及该怎么做”。有了这个工作指南,我们即可按部就班的做事情,不用临时去思考到底该怎么做,进一步避免分歧导致工作的停滞甚至争吵。当团队规模越大,工作流的意义越明显,甚至没有工作流就没有协作可言。

为什么是Git而不是SVN?首先,Git相对于SVN的优势不再此处讨论,毫无疑问的是Git意味着更高的生产效率。根据我的经验,团队中各种排斥Git的原因只能归结为一个字”“。如果团队中至少有一位非常熟悉Git的布道师,再加上老板的支持,其实是很容易执行下去。根据我们团队目前的情况来看,部分美术同学都会很主动的去学习Git,并在工作中使用得非常好。

下图是工作流图:

如图所示

此处采用双主线分支的设计,masterrelease都为主线分支,即长期存在的分支。master分支为开发主分支,需要保证相对稳定(不能阻塞其他人的工作)。日常的功能开发都是从master分支checkout新的分支*task-n*进行开发,当功能开发完成并验收后合并到master分支,此时可以删除task-n分支,也可以随时再checkout功能分支进行bug修复。

对于一些长期存在的功能开发,例如策划数值配置,美术资源交付可以建立特殊的(长期存在)的功能分支,例如design, *art*。其它功能分支如果需要依赖这些资源,可以在开发过程中合并到task-n,因为这些分支其实也是和task-n等价的,也可以随时删除了再重新从master分支出来。

当开发完成里程碑需要发布正式版本时,将master分支合并到release分支,并继续在release分支进行最后交付的迭代,可以迭代多个版本,例如从v0.0.1-rc1-rcn,当到某次迭代稳定时则发布正式的版本,例如v0.0.1。因为某些团队成员可能还要继续下一个版本的功能开发,所以需要将release分支的修改同步到master分会,但master分支的修改次数不再同步到release(下个版本规划的内容不需要同步到当前发布分支)。

正式发布的版本(v0.0.1)如果发现bug,则从该tag新建hotfix分支进行修复,修复完成后再合并到release分支进行测试验证并进一步发布新版本v0.0.2,热修复内容也需要同步回master分支。

功能开发过程中也可以随时根据需要去合并master的内容,例如合并一些功能模块的开发内容。合并的提交点以紫色表示。

因为整个开发工程中会不断新建/删除/合并分支,为了更好的理清提交线,可以使用rebase方式合并。

结合CI/CD会很香,:-)