Git
开发规范
日常开发中,我们经常会跟
Git
打交道,可能服务器不一样,但是命令和规范基本都是一样的。
一.常驻分支
常驻分支为一个正常开发上线流程应该会有的分支。
1.master
/prod
/production
主分支,又称为生产环境分支,有时可能会使用(prod
/production
)来代替,生产环境的部署分支,生产环境相关操作,如:打包等应从改分支进行。
2.dev
全称(Develop),开发分支,我们正常的需求开发等,应该使用该分支。开发环境的部署和打包,使用该分支。
3.pre
全称(Pre production),预生产分支,一般根据项目而定,有的项目可能因为资源不足等原因,没有预生产分支,预生产分支,又为线上测试环境。预生产环境打包应从此分支进行。
二.临时分支
临时分支,顾名思义,是不会常驻的,一般,在merge
完,完成使命后,会被删除。
1.feature
新需求的开发分支,从develop
分支上面分出来的。开发完成后,要merge到develop分支。功能分支的命名,可以采用feature_*
的形式命名(*为需求名称拼写,如feature_user_list
)
2.hotfix
Bug修复分支。为了修复某个bug,从常驻分支上面分出来的。修复完成后,再merge到对应的分支。Bug修复分支的命名,可以采用fixbug_*
的形式命名(*为bug说明,如fixbug_user_list
)
三.开发流程
1.正常开发
- 从
dev
分支切出一个新分支,根据是新功能还是bug,命名为feature_*
或fixbug_*
。 - 开发者完成开发,提交分支到远程仓库。
- 开发者发起
merge
请求(可在gitlab页面New merge request
),将新分支请求merge
到develop
分支,并提醒代码检查人员
进行review
。 代码检查人员
对代码review
之后,若无问题,则接受merge
请求,新分支merge
到develop
分支,同时可删除新建分支;若有问题,则不能进行merge
,可close
该请求,同时通知开发者在新分支上进行相应调整。调整完后提交代码重复review
流程。- 转测时,直接从当前
develop
分支merge
到pre
分支,重新构建测试环境完成转测。 - 测试完成后,从
pre
分支merge
到master/prod
分支,基于master/prod
分支构建生产环境完成上线。并对master
分支打tag
,tag
名可为v1.0.0_2020.05.15.1
(即版本号_上线时间)
2.开发过程中,修复Bug
即前一个版本已经转测但未上线,后一个版本又已在开发中并部分合并到了dev
分支,转测后测试环境发现的bug
需要修复,但是dev
分支此时又有新内容且该部分内容目前不计划转测,可以从pre
切出一个bug修复分支。完成之后需要同时merge
到pre
分支与dev
分支。
3.生产环境Bug修复
生产环境的Bug分两种情况:
紧急Bug
:严重影响用户使用的为紧急Bug,需立即进行修复。如关键业务流程存在问题,影响用户正常的业务行为。非紧急Bug或优化
:非关键业务流程问题,仅影响用户使用体验,或出现频率较小等,为非紧急Bug,可规划到后续版本进行修复。
修复紧急Bug
:
:需要从master
分支切出一个bug修复分支,完成之后需要同时merge
到master
分支与dev
分支(如果需要测试介入验证,则可先merge到pre
分支,验证通过后再merge
到master
分支上线)。