游戏版本分支管理策略
2022-02-19
我们游戏团队使用gitlab作为代码仓库，采取git来做分支版本管理，我们采用Git Flow来进行分支管理和版本管理。
我们游戏约定每周二8点会进行全服关机维护，维护时间一般为1小时，在维护期间内会进行关服、代码分支切换、数据检查备份、移服合服等工作。维护期间很重要的一个内容就是代码分支切换，把本周要外放的代码内容换到线上运行。
我们的游戏采取以下分支：
- master分支：主干分支，是稳定分支，这个分支只能从其他分支合并，不能在这个分支直接修改。另外master分支的代码并不会直接上线上机器。
- release分支：正式版本分支，全服服务器都会用该代码分支（除了test分支），每周自动生成一个新的版本号分支，如rel_2022_02_15，版本日时线上代码自动切换到release/rel_2022_02_15。
- test分支：灰度测试分支，这个分支主要用于发布一些风险的内容改动，这些内容先在少量机器上跑（灰度），test同样从master分支打出，并且test内容会在周二12点merge回master。
- feature分支：开发分支，我们的新增功能或者是代码修改，需要先在开发分支进行开发，后续再合并到主干分支和版本分支。
通过上面的分支解析，我们知道我们线上服务器跑的分支版本一共有2个，分别是release和test，理论上test的服务器数量一般为全部服务器的2~5%，比如我们有100台服务器，我们本周线上的服务器就可以分配为：95台release分支的服务器，5台test分支的服务器。
分支管理流程，我们约定每周二8点进行停机维护：
- 我们维护一个master主干分支，周二12点首先将上周test内容merge回master，幷从master打出下周的正式版本release分支和test分支，因为下周二是2022_02_22，因此我们从master打出release/rel_2022_02_22和test/test_2022_02_22，我们线上代码会在2022年2月22日8点自动或手动切换为该分支。
- 周三我们接到一个全服改动的新需求，因此我们从master分支打出开发分支，命名为feature/newyear_pk。
- 在开发分支feature/newyear_pk进行开发，开发完毕后，发起merge request，打算把代码merge回master、release/rel_2022_02_22和test/test_2022_02_22。因为项目设置了必须代码审查，因此代码提交被block。
- reviewer进行代码审查，提出了一些修改意见，作者继续在feature/newyear_pk进行修改，修改后reviewer确认无误后，批准了代码提交。在feature/newyear_pk的代码修改被合并到master、release/rel_2022_02_22和test/test_2022_02_22。
- 周四我们接到一个需求，但改动有风险，我们决定先把改动灰度测试一周，因此从test/test_2022_02_22打出开发分支，修改后的代码提交到test/test_2022_02_22。待review通过后，正式merge到test/test_2022_02_22。
- 周五线上运行中发现代码有bug，需要热更修复，因为是修复全服的代码，因此从master打出开发分支，因为是hotfix，所以我们把分支命名为hotfix/newyear_pk_fix_reward。在代码修改通过且QA验证后，我们发起merge request，请求合并到master，release/rel_2022_02_15，test/test_2022_02_15，release/rel_2022_02_22，test/test_2022_02_22。
- reviewer审查后批准合并。
- 代码热更到全部服务器，bug修复完毕。
- 时间来到2022_02_22早上8点，维护时间已到，全服关机，切换分支为release/rel_2022_02_22，test/test_2022_02_22，启动服务器，维护完毕。
- 周二12点把test/test_2022_02_22 merge回master，幷打出下周release,test分支。
下面用一张一周的开发流程图表示我们的分支管理策略：
