简明版GIT分支管理流程

背景

当前公司使用的是gitlab做代码版本控制，由于目前部门已经有了一套git分支管理流程，但不规范，也没有考虑多版本并行开发及持续部署的情况，所以需要重新整理一下。目标是在尽量少的改动下实施好分支管理来满足逐步增长的业务需求。

分支

由于持续集成已经针对不同分支进行集成部署，为了不改变持续集成的脚本，规划三条长久分支

• master: 生产环境分支，保护分支，只有团队管理者有权限合并，其他人提交需要提交PR。
• release: 测试环境分支，保护分支，只有测试人员有权限合并，其他人提交需要提交PR。
• dev: 开发环境分支

规划以下临时分支

• feature: 功能分支，针对一些比较独立大的功能可以拉取功能分支，测试上线完成后需要删除。
• hotfix： bug修复分支，从master中拉取的分支，修正bug上线后删除。

开发流程

开发人员在dev分支进行开发，部分较大的feature开发需要单独拉取分支进行开发。原则上提交到dev的代码当天都可以编译通过，需要设立一个隔夜发布(Nightly Deploy)的持续集成的定时任务。

测试流程

开发人员全部开发完成后，需要在gitlab上提交一个pull request，由测试人员进行review的pr进行merge。后面通过持续集成进行部署

生产流程

同测试流程，合并到master后由运维同事进行生产部署。验证完成后需要打tag，命名规则是tag-[version]-[date]。

功能分支开发流程

本地拉取分支以后做功能分支开发，也可以推送到远程功能分支，需要开发完成后再合并回到dev，然后删除feature分支

hotfix流程

当生产环境发现问题的时候，可以从master中拉取hotfix分支。为了减低影响当前开发的情况，需要额外新建一个持续集成任务，专门针对hotfix分支部署测试环境。hotfix分支需要分情况进行处理

• 当目前开发版本暂时没有部署到测试环境，可以直接把hotfix分支部署进行验证即可
• 当目前开发版本已经部署到测试环境，需要评估一下其他中间件的修改（如数据库修改）是否会影响bug功能的回归。如果会，建议把bug合并到当前版本一起上线，如果不会，测试环境优先部署hotfix版本进行部署。

测试完成后，按生产流程步骤进行操作即可，上线回归完成后需要删除hotfix分支

多版本开发流程

理论上最多两个版本并行开发，同时如果两个版本能否并行开发也要做好前期的分析工作，比如是否前后有依赖，数据库的增删查改是否会相互影响等。在评估没有问题之后，再规划保存代码的分支如下

• dev: 先行版本的开发分支
• dev-after: 后行版本的开发分支
  同时新建立持续集成的任务，专门针对dev-after分支开发环境部署。