自用的GIT分支管理模型

目录

前言

一、背景说明

二、分支管理

1、分支类型

2、版本号规约

3、分支管理规则

4、补充说明

三、示意图


前言

项目使用GIT作为代码管理工具,使用GIT时很重要的一项工作就是进行分支管理,目前行业已有多种GIT分支管理模型,本文章详细描述了本人所管理的项目使用的GIT分支管理模型。


一、背景说明

本人目前管理的项目为微服务架构,容器化服务的系统,使用GIT作为代码管理工具,存在多个需求并行开发的情况,且不同需求的上线时间不统一。在此项目要求下同时结合公司当前的测试流程与上线管理规范,设计了此GIT分支管理模型。

二、分支管理

本GIT分支管理模型基于阿里AoneFlow开发分支管理模型,结合项目实际与公司当前管理流程做了部分修改。

1、分支类型

使用以下两类共4种分支类型:

固定分支:

master分支:主分支(生产分支),代表当前项目的基线,保护分支,不允许直接修改,只接受合并请求。保证master代码与正式生产环境发布的最新代码相同。

develop分支(dev分支):测试分支(开发提测分支),用于需求提测和测试环境部署,保护分支,不允许直接修改,只接受合并请求。

临时分支:

release分支:集成分支,用于集成和发布,在上线发布前对各feature分支进行集成和部署,不同的环境下可以使用不同的release分支(如预发环境release_pre,生产环境release_prod)。

feature分支:特性分支(变更分支、需求分支),用于具体的需求开发。

hotfix分支:BUG修复分支,用于线上BUG修复与重大事故应用版本回滚。

2、版本号规约

版本号用于项目发布后master分支添加tag,记录版本,常用的版本号为三位数版本号,其构成如下:

V主版本号.次版本号.小版本号

例如:V1.0.0、V1.2.0、V1.2.5等

​​​​​​​3、分支管理规则

代码合并需遵循以下几条基本规则:

规则一:开始工作前,从master分支创建feature分支。

为每个需求单独创建一个通常以feature_前缀命名的特性分支,然后在这个分支上提交代码修改。前缀命名规则为OA号-需求名称。

规则二:提测时将feature分支合并到dev分支。

需求开发完成充分自测后,根据测试管理的要求,提交提测申请,将提测需求的feature分支合并到dev分支,测试自动将dev分支代码发布到测试环境。

规则三:上线前从master分支创建release分支,合并所有需上线的feature分支到release分支。

若生产环境存在灰测环境,可先将release分支发布到灰测环境进行生产验证。若只有生产环境,则将release分支发布到生产环境。上线时可使用jenkins或流水线选择release分支发布。

规则四:发布完成后,合并相应的release分支到master分支,在master分支上添加tag版本号,同时删除该release分支和相关联的feature分支。

规则五:生产环境出现BUG需修复,从master分支最新版本拉取hotfix分支,修复后合并到dev分支测试,测试通过后将hotfix分支发布到生产环境,发布完成后合并hotfix分支到master分支,同时删除该hotfix分支。

规则六:线上出现重大事故需回滚代码,可从master分支历史版本创建hotfix分支后发布,线上应用回滚后需及时修复BUG并合并回master分支,master分支本身不得回滚。

​​​​​​​4、补充说明

  1. feature分支需经过严格自测之后才能合并到dev分支,合并dev分支需提交提测申请,不得随意合并;
  2. 每次生产发版后dev分支和所有正在开发的feature分支需从master拉取最新代码,保持代码与生产最新版本一致;
  3. 只有hotfix分支和release分支才能往master分支上面合并,feature以及dev分支均不能直接合并到master分支;
  4. 所有临时分支在合并到master分支后需及时删除,避免分支过多,无开发任务时gitlab中应只存在两条固定分支;

三、示意图

自用的GIT分支管理模型_第1张图片​​​​​​​

你可能感兴趣的:(开发,git,git,java)