本文目的:
实现多个项目同时进行的git多版本管理工作流。
名词解释:
feature-XXXX:特性分支指CCS中一个项目或者一个迭代,在该分支上开发,完成后,合并,最后,删除该分支,开发人员(xxxx可以自己根据该分支)
develop :开发分支,开发环境基于该分支构建,开发人员关注该分支,一个大融合分支,该分支体现了此时进行的所有项目的特性功能。
test(release):测试分支,测试环境基于该分支构建,测试人员关注该分支,该分支包含即将上线的特性功能。
hotfix:为了修复某个bug,从master分支上面分出来的。修复完成后,再merge到master分支以及其他分支
master:生产环境稳定分支,生产环境基于该分支构建
目前现状:
3、产生问题:
从上图可以看出 当前分支管理无法实现 多版本并行开发,是一个串行的工作流方式。
1、当某个迭代在develop分支完成生命周期即封板后,此时代码进行到test分支,发现代码有bug
目前所见做法有 部分开发者直接在test分支修改代码,develop分支不修改,等到上线后master反合;部分开发者在test修改后,develop同时改掉。
2、同时有 A、 B 2个迭代, A迭代计划先上线,B迭代计划在A后面上线,只能A迭代生命周期进行到test才能释放出develop分支给B迭代使用。
3、同时有 A、 B 2个迭代, A迭代计划先上线,B迭代计划在A后面上线,突然接到通知B需要在A前面上线,此时A占据着测试环境,需要增加很大工作量回退代码。
上述问题大大影响了开发效率,测试效率,也会产生代码丢失的风险等。
解决方案
** 解决方案-工作流图:**
流程图解释:
** 1、**场景
项目同时并行 :1、迭代33 ; 2、迭代22开发 这2个项目;
2、准备
从master拉出2个分支 feature-迭代33 2、feature-迭代22。
3、开发自测联调阶段(feature->develop)
3.1、 负责这2个项目的开发人员在各自这2个分支上开发。
3.2、开发完成,想到环境上验证自己开发东西是否ok或者和前端进行联调。可以将各自分支上的代码merge到develop分支,此时以develop分支部署开发环境,就具有了这2个项目的所有特性;
3.3、如果开发环境验证时发现存在bug,此时修改代码请在各自的feature分支上修改,修改完成再将自己的分支代码merge到develop环境,部署一下验证。
4、提测阶段(feature->test(release分支))
4.1、到此阶段前后端已经联调完毕,自测Ok需要发起测试验证即提测,此时迭代22开发在迭代33前上线,保险起见将master分支反合到该特性分支(feature-迭代22)以及test分支,
再将test分支代 码反合到feature-迭代22分支(这么做减少冲突)最后将feature分支merge到test分支,部署test分支提测。
4.2测试过程中发现bug,在各自分支修改,修改后合并到test分支,再部署验证,别忘了也merge到develop分支。验证 ok,选取时间点上线。
5、上线阶段(test(release)->master)
可以拿test(release)分支上线,记住上完线要反合master分支,打tag
说明:在第4步中,应该有一个release分支,但是因为环境不支持等原因,以固定的test分支代替其作用;
版权归原作者 Simple_Demo 所有, 如有侵权,请联系我们删除。