自用的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中应只存在两条固定分支；

三、示意图

​​​​​​​