我们目前的分支管理模式
版本发布:
- 正式版本和预发环境发布都是基于 release 分支。
- 线上问题修复是基于当前 release 分支创建新的 hotfix 分支。
开发阶段:
- 开发分支是基于 develop 分支,迭代开始会将上个版本 release 分支合并到 develop 分支。
- 个人分支是基于 develop 创建新的个人分支。
提测阶段:
- 测试环境基于 develop 分支,bug 修改完成后由个人分支合入 develop 分支发布。
- 预发环境基于 release 分支,bug 修改完成后由个人分支合入 develop 分支再合入 release 分支发布。
比较主流的 Git 分支简介
- master - 主分支 最稳定版本的分支,正式发布的版本都是基于 master;
- develop - 开发分支 更新和变动最频繁的分支,正常开发过程的分支都是基于 develop;
- release - 预发分支 一个版本全部功能开发完成后 ,提交测试和bug修复的分支;
- feature - 功能分支 包含每个开发人员开发的功能点,feature 开发完成后合入 develop;
- hotfix - 正式版本中进行问题修复的分支。
最近项目开发中分支管理遇到的问题
-
提测阶段 预发发版的问题
由于 jenkis 脚本限制,预发分支必须是 release-* 开头,中、所以无法直接使用 develop 分支发版,而且后续迭代开发也是基于 develop 分支,所以预发问题回归阶段的 bugfix 同时必须合入 develop 和 release 分支,此时,有两种代码合入方式:
a:个人分支 dev-xx -> develop -> release
优点:会带上其他人的commit,并一同发布预发,减少发版次数
缺点:无法控制他人代码质量或者代码目前是否可以发布预发,可能导致新引入问题和版本问题
b:个人分支 dev-xx -> develop dev-xx -> release
优点:当前预发发布版本可控
缺点:可能增加发版次数
-
线上问题修复时创建hotfix分支的问题
hotfix 可能基于 release 分支或者其他的 hotfix 分支,如果要修复线上问题,则会有以下问题。
a. 繁琐
- 分支创建时需要向上一个发版人确定或者在 jenkis 发版记录找;
- 发版完成后需要将代码合入 develop,否则下个迭代功能上线以后会丢失此次的问题修复代码;
b. 容易引入问题
- 如果没有确定正确的线上分支或者确定了错误的分支,则线上会重复出现历史问题;
- 如果发版完成后代码没有合入 develop,则下一迭代发版后线上也会重复出现历史问;(高频问题点)
-
并行迭代时的分支管理问题
真实场景描述:
工作台 v1.6 迭代开发过程,我们有正常的开发分支 develop,且基于 develop 创建新的个人开发分支 develop-x1、develop-x2等。在 v1.6 结束阶段,由于企业微信迭代优先级问题,全员投入企业微信 v1.0 迭代开发,此时由于 v1.6 未上线,且企业微信迭代和 v1.6 无法同时上线,所以创建新的 develop-wxwork 分支,此时正常的 develop 分支则是停用状态。
后续企业微信上线阶段,则衍生 release-ww-v1.0 分支完成发版,同时由于预发测试和正式版本差异,预发则基于 release-ww-v1.0 分支创建 release-ww-stage-test 分支,后续线上hotfix 则是基于 release-ww-v1.0。
在企业微信上线成功后,则是开始 v1.7 迭代开发,且 v1.7 基于 v1.6,此时部分 v1.7 功能合入到 develop ,但在 v1.7 迭代开发中途,由于优先级问题则是开展 V1 和 V2 迭代,且 V1 和 V2 是基于目前线上版本 release-ww-v1.0 开发,并且先于 v1.7 迭代开发,且 V1 、V2 迭代功能无关联并不同时上线,所以,则产生两个新的开发分支 develop-v1 和 develop-v2 进行。
此时,迭代开发、测试发版、线上问题修复的分支管理已经比较混乱,难以维护。
解决方案思考
-
上线流程优化 - 正式和测试发布使用 master 分支,预发问题验证则是基于 release,每次迭代分支总是基于 master 创建 develop,线上问题修复基于 master 创建个人 hotfix 分支,验证完毕后合入 master 发布。
优点:
a. 线上问题修复总是基于 master ,不存在不明确当前线上版本和 hotfix 代码丢失问题;
b. hotfix 不需要多次合入其他分支;
c. 并行开发 develop 分支总是基于 master,不需要确定当前版本,且冲突较少;
缺点:
a. 如果发版异常,即时回退比较麻烦,需要在 master 分支撤回异常 commit,再发布;
b. 需要变更目前的开发上线发版流程和修改 jenkis 脚本;
-
上线流程优化 - 正式发版和预发发版还是使用目前流程,使用当前迭代 release 分支发版,但是每次线上发版完成后必须将代码合入 master,线上问题修复、后续迭代开发、基于线上版本的并行迭代开发都基于 master 分支创建新分支。
优点:
a. 不需要变更当前流程和修改脚本,只需要维护好 master 分支;
b. 新迭代开发分支创建、hotfix 分支创建方便,都是基于 master;
c. 线上发版需要回退时迅速,只需要回退到上次的 release 分支即可。
缺点:
a. 每次完成线上发版以后,代码必须合入 master;
b. 如果线上发版后代码忘记合入 master,则下次发版会发生线上代码丢失导致历史问题重现。
补充:
可用 jenkis 脚本配置代码上线以后自动合入 master 的功能,这样会很大程度避免线上代码丢失的问题。
- 测试流程优化 - 目前测试和预发测试阶段,由于同时存在 release 和 develop,个人分支需要同时合入两者。如果提测和预发测试都是基于release 分支修改,此时停用 develop ,那么只需要合入 release 即可,下个迭代 develop 可以再基于 master 和 release 创建。