一种适合后端团队代码的GIT分支管理办法

  每个公司甚至公司中的不同团队对代码的分支管理都是有所差别,网上也有很多人分享了他们的分支管理规范,相信很多有一种感觉就是采用了他们的方法然后真正实践起来总是有些水土不服,我个人认为分支的管理需要结合团队规模、应用类型、发布流程等实际的情况来制定规范。下面我将介绍一种适用于后端开发团队且做toC产品业务后台的代码分支管理办法。

不同业务代码的管理需求差异

业务后台 基础工具SDK/中间件 独立部署企业软件
多版本 不需要 需要 需要
迭代频率 1-2周 少更新 少更新
更新方式 灰度更新 更新SDK版本号 补丁包更新,不同版本不同的补丁包
维护版本 最近的2个版本,主要是发布失败会滚用 每个release版本都需要单独维护 每个客户的版本都要单独维护

从上面的对比结果看,在做to C 产品的业务后台的,相对于开源软件,企业软件,中间件等对于版本控制的生命周期没有那么长,不需要对每个release版本进行长时间的维护跟踪,我们的服务更新永远只有一条线,因为我们的服务面向的研发只有自己的团队,就算出现版本兼容,在随后的几个版本也能快速升级上来。需要做好版本控制的仅仅在于最近上线的几个版本中。

一种适合业务后台开发的GIT分支管理模型

  1. develop: 开发分支,平常开发的代码都提交到这里,为了简化,这里可以不用根据版本号进行细化分支。
  2. feature/xxx: 特性分支,这个目录下的分支,用于开发一些新特性,或者说是最近不需要上线的功能。
  3. stage: 测试分支,这个分支代表测试环境的代码,测试环境的镜像/程序必须通过该分支来构建,保证测试结果与代码的一致性。
  4. master:生产分支,这个分支代表生产环境的代码,生产环境的镜像/程序必须通过该分支来构建,部署后打tag确定release版本,对应我们的场景(业务后台),我们只需要维护最近的2个release版本,一般情况下只能回滚最近的版本。
  5. bugfix-xx: 补丁分支,这个是一个临时分支,从待修复版本的起点开分支,每个分支对应一个补丁程序,在本地验证后,需要把补丁合并到stage进行测试验证,验证通过后再将补丁合并到master进行修复,同样也需要把补丁打到develop。

工作中常见的场景

  1. 开发周期中,所有的功能在当前周期都能完成,需求评审确认通过且开发任务符合预期

  时间线:D1→D2→D3→D4→S3→M2 。因为经过评估在下一个发布时间前开发人员能够将D1到D4的4个功能完成开发,所以在次期间我们只需要保证这个分支的功能能正常演进即可,尽量不要引进太多的分支。

  1. 开发周期中,所有功能在当前周期完成,需求评审确认通过,少部分功能上线时间待定,任务进度符合预期

  这个时候可能存在2条线,大部分人参与当前版本的功能开发(develop分支的演进),少部分人进行未来版本上线的需求开发(F1,F2,F3)。F3→S2 这个合并尽量等到需求拍定上线版本后合并到stage给测试人员测试。

  1. 线上BUG的修复

  确认BUG后,如果是测试人员反馈回来的一般会是在JIRA 上提单,我们可以根据jira的issue Id,在master 上 创建一个bugfix-jira-xx,接下来在这个分支上完成补丁的开发(B1→B2),之后合并补丁到stage分支进行测试环境的部署(B2→S4),等待测试人员的验证,验证完成后将补丁合并到master和develop分支(B2→M3,B2→D5),并打一个小版本号的tag。

  1. 有个新功能,老板想立马上线,但是发版的时间还没到

  这种情况,把这个功能当成一个超前的feature处理,我们上面说的feature是一个未来版本的功能,可以走未来版本的测试上线流程,这里的feature 是一个超前的功能,我们需要走类似bugfix的流程,进行一个快速的开发上线。

如果你们有遇到比较棘手的分支管理问题,欢迎留言交流。