Git & Gitlab 工作流

一、Git工作流

1、开发流程

在master分支或功能开发分支切出个人开发分支推荐命名规则：[开发者姓名简拼]/[类型]-[命名]，
开发者姓名简评有冲突可后缀添加工号
类型包括：fix/fixbug、feat/feature等，
命名可以自定义，推荐
有jira的使用jira-[JIRA_ID]
有confluence，使用confluence-[confluence_pageId]
其他逻辑相同
功能开发完毕后提交并推送个人分支至远端
本地切换到dev分支并更新 git checkout dev && git pull，合并个人远端开发分支。注：至于使用git pull 还是 git featch，可参考此图

解决冲突后推向远端dev分支 git push origin dev
若gitlab-CI配置正确，提交dev分支/任何分支创建特定tag（test-xxxxx） 会自动触发 CI、CD 流程
测试环境通过后，在本地自己开发分支合并master分支
解决冲突后，push代码至自己远程的开发分支
在gitlab提交merge request，目标分支为master，@相关人员review代码，确定无误后，负责人合并MR
在Gitlab中在master分支创建tag（release-xxxx），触发CI构建正式环境包
在http://web.xxxx.com/提交部署申请，待申请通过后会自动部署至生产环境

在整个研发流程中，
部署测试环境可一键完成，即 push至远端特定测试分支 或 任何分支创建特定tag并push到远端
部署生产环境增加review cod