分支管理在创建项目时(一般是面向服务的项目,少数工具或辅助项目可以很简单),会针对不同的环境创建三个永久分支:develop:开发环境的稳定分支,公共开发环境构建在其上。 预发布:测试环境的一个坚实分支,测试环境是基于它构建的。 Master:生产环境的一个坚实分支,生产环境构建于此。 仅用于发布新版本,除了从预发布或生产环境的Bug修复分支合并,不接受任何其他更改。在正常的开发工作中,开发人员会根据需要创建两种类型的临时分支:功能分支(feature branch):它是为了开发某个特定的功能而从开发分支分支出来的。 开发完成后,合并到开发分支。 功能分支可以以特征-(任务号)的形式命名。Bug修复分支:为了修复一个bug,从永久分支中划分出来。 修复后,合并到相应的分支。 修复分支可以用fix Bug的形式来命名——(Bug数量为单个)。过程规范从开发分支中切出一个新的分支,根据是函数还是bug,命名为feature-*或者fixbug- *。 开发人员完成开发,提交分支到远程仓库。 发起开发者的合并请求(gitlab页面的“新合并请求”),请求新分支合并到开发分支,提示reviewcode reviewer审核代码。如果没有问题,接受合并请求,将新分支合并到开发分支,删除新分支。有问题就不能合并。您可以关闭请求,并通知开发人员对新分支进行相应的调整。 调整后,提交代码并重复审查过程。 调试时,直接从当前开发分支到预发布分支,重建测试环境完成调试。 测试完成后,从预发布分支合并到主分支,基于主分支的生产环境完成并上线。 并标记主分支,标记名可以是v1.0.0_2019032115(即版本号_在线时间)。在测试环境的正常开发流程和Bug修复流程并行开发的过程中(即前一版本已转移但未上线,后一版本已在开发中并部分并入develop分支),转移测试后在测试环境中发现的Bug需要修复,但develop分支 完成后,您需要同时合并到预发布分支和开发分支。 合并时参考“正常开发流程”。 过程的目的如下:并行开发和测试环境Bug修复过程生产环境中的Bug分为两种情况:1 .紧急bug:严重影响客户使用的为紧急bug,需要立即修复。 如果关键业务流程出现问题,就会影响客户的正常业务行为。 非紧急Bug或优化:仅影响客户体验或发生频率较低的非关键业务流程问题属于非紧急Bug,可以计划在后续版本中修复。 生产环境有两种bug未完待续。 欢迎关注我的微信微信官方账号,及时获取最新参考。