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分支上线）。
四.流程图
