一、背景：

大多数公司为了可以快速迭代，一般只有两个环境，一个是测试环境，另外一个是线上环境。这个时候问题就来了，如果线上出现bug要如何修复才不会影响当前版本测试。如果多个版本同时迭代开发，如何才能保证测试上线互不影响呢？

童鞋们可以先想想，后面会针对上述场景，进行详细的说明。

二、当前状况

2.1 当前环境

当前有两个环境：测试环境、生产环境。

两个环境都是采用k8s集群搭建而成

2.2 git分支

• master:生产环境对应分支代码、分支会永久存在。

• dev:开发环境对应分支代码、分支会永久存在。

2.3 问题场景

2.3.1 版本无法区分问题

不管当前有多少个版本的开发，都会统一在dev分支中开发，dev分支合并到master的条件是：dev最后一个版本测试完毕之后。基于当前这种流程，没办法将其它小版本单独发布到线上。

2.3.2 bug修复问题

因为当前只有两个环境，所以每当线上出现bug的时候，都是以master分支作为源头，创建一个bug分支，开发人员将bug分支修改完毕之后，就以当前的bug分支作为构建镜像的代码源，用来启动容器，这样势必会导致原本的dev分支的容器被覆盖，导致dev中的版本测试受到影响。

2.3.3 分支命名不规范

没有一个明确的分支命名规范，gitlab中出现各种各样的分支，没办法通过分支名字推测出分支的作用，有些分支都发布上线了，还是没有删除。

三、Git flow工作流程

在开始解决上述问题之前，我们先来了解一下Git flow工作流程，如下图所示：

官方博客：https://nvie.com/posts/a-successful-git-branching-model/

官方给出的发布流程中有五个分支，其中除了develop和master两个分支是永久性存在的，其它的分支都是临时存在的，发布上线或者修复bug之后，都会删除。

3.1 分支介绍

• feature branches：版本开发分支

• develop：测试分支

• release branches：预发布分支

• hotfixes：bug修复分支

• master：线上分支

3.2 具体流程

每一个版本的需求就是一个feature branches分支，当版本需求开发完毕之后，需要合并到develop中，提供给测试人员测试。当feature branches分支对应的版本测试完毕之后，将develop分支发布到release branches分支中，等待发布上线。发布完毕之后删除对应功能的feature branches分支。

release branches核实无误，将代码合并到master分支中，并打上对应的tag，最后将tag发布到线上。master线上发布完毕之后，删除对应的release branches分支。

线上如果出现bug，以master为源头创建一个hotfixes分支，修复完毕之后再合并到master和develop分支中。hotfixes分支合并完毕之后，也需要即可删除分支。

四、版本发布流程

正如齐白石老先生说的：“学我者生，像我者死”一样，Git flow分支模型确实非常优秀，可以解决很多问题，但是我们需要跟我们的实际项目进行适配。就比如我们master环境没有版本的概念，因为我们从始至终就只有一个线上环境，不像jdk一样，会同时维护多个版本的线上迭代。所以我们需要对这个Git flow分支模型进行改造。

4.1 改造点

4.1.1 feature branches合并release

feature branches分支对应功能测试完毕之后，直接将feature branches代码发布成release branches分支，不再通过原本的develop分支。这样的好处是可以有效的防止develop分支包含多个feature branches的功能，难以提取对应版本发布到release branches分支中。

4.1.2 master非tag发布

master直接用当前分支代码作为镜像代码源，因为线上只有当前最新版本，不需要划分多版本代码。但是每次发布时候都需要打tag，用于记录发布版本对应的说明，后期好回溯。

4.1.3 release branches分支

release branches代码永久性保留，release branches对应预发布环境。

4.1.4 部署bug分支环境

线上出现bug，为了不污染release环境，我们需要部署专门用来测试bug的环境。bug测试完毕之后才能合并到release环境中，等待版本上线。

4.2 环境

1. 测试环境

2. 线上环境

3. release环境

4. bug环境

bug环境对应镜像服务分支默认为release分支代码，如果出现bug，需要将涉及到的服务切换到bug分支。测试通过之后，将代码合并到release分支，并将镜像服务分支切回release，最后删除对应bug分支。

4.3 分支

• feature branches：版本开发分支

• dev：测试分支（永久分支，对应测试环境）

• release branches：预发布分支（永久分支，对应预发布环境）

• hotfixes：bug修复分支

• master：线上分支（永久分支，对应线上环境）

4.4 分支命名规范

• 版本开发分支命名规范：feature_产品版本号-需求说明

• bug分支命名规范：hotfixes_负责人_bug说明

• release branches（release_master）：名称固定

• dev：名称固定

• master：名称固定

4.5 正常发布流程

1. 根据产品需求，以master为源代码创建feature branches，命名规范为：feature_产品版本号-需求说明。

2. feature branches开发自测完毕之后，合并到dev分支等待测试人员测试。

3. 测试人员测试通过之后，通知分支开发负责人将需求发布到预发布环境。

4. 开发人员将feature branches代码合并到release branches中，等待发布上线。

5. 得到允许发布到线上的命令之后，将release branches代码合并到master分支，并打上tag记录。

6. 将上线版本对应的feature branches删除。

4.6 bug修复流程

1. 出现bug之后，以release branches为源码创建hotfixes分支，命名规范为hotfixes_负责人_bug说明。

2. hotfixes分支开发自测通过之后，修改bug环境对应服务的分支指向，启动完毕之后通知测试人员开始测试。

3. 测试人员测试通过之后，通过对应开发人员。

4. 开发人员收到通知后，就可以将hotfixes分支代码合并到release branches和erp-dev分支中，并修改回bug环境对应服务的分支配置（默认为release分支）。

5. release分支功能发布线上之后（bug修复的代码包含在里面），将对应的bug分支删除。

4.7 版本发布流程图

五、demo流程演示

5.1 正常发布流程

以master分支为源头创建如下分支： 

现要求：

feature_v1_test1：开发时间为5天，从2021-04-06开始开发 预计发布日期2021-04-10
feature_v1_test2：开发时间为2天，从2021-04-06开始开发，预计发布日期2021-04-08
feature_v1_test3：开发时间为1天，从2021-04-06开始，预计发布日期2021-04-06

开始开发feature_v1_test1、feature_v1_test2、feature_v1_test3版本代码。 

开发完毕后，合并到dev中，等待测试人员测试。 

测试人员在dev环境中，将feature_v1_test3版本功能测试完毕后，开发人员将feature_v1_test3分支合并发布到release分支。

release分支最后检测发现有bug，在release分支进行bug修复，修复完毕后合并到dev中 

release分支最后验收完毕，将release分支合并发布到master上线。 

发布master成功之后，将feature_v1_test3分支删除（本地和线上）。 

5.2 bug修复流程

以当前release分支为源头，创建一个hotfixes_linzhiqiang_login分支，用于修复线上bug。 

bug修复完毕之后，以hotfixes_linzhiqiang_login分支作为测试环境对应服务分支，测试通过之后，将hotfixes_linzhiqiang_login合并到release分支中，等待发布上线。

release预发布测试bug是否正确被修复，测试通过则将release分支发布到master分支上线。

发布成功之后，则将bug分支删除，一般情况下，bug分支不需要发布到远程仓库中。

5.3 注意事项

master每次发布都需要打个tag，对本次版本进行说明解释。

对应版本发布到线上之后，需要删除对应的feature branches分支代码。

六、总结

上面讲述了如何利用Git flow适配我们自己项目发布流程。但是当前版本发布流程还是会存在某些特殊问题。

6.1 feature branches当天多版本上线问题

如果feature branches分支中有两个版本需要当天发布，一个是中午，一个是下午，因为目前我们release分支只有一个分支，所以没办法兼容这种情况，遇到需要特殊处理。

6.2 bug时效高于release分支

如果release分支预计是当天晚上发布，但是当天早上有一个紧急的bug需要立即修复。这个时候就不能以release分支作为源头拉取bug分支了，必须以master为源头拉取分支。修复之后合并到master和release分支中。

6.3 feature branches合并到release分支冲突

因为我们是从feature branches直接合并到release分支的，过程中跳过dev分支，如果修改同一个文件，会大大增加冲突概率。

虽然特殊问题需要特殊处理，但是这种情况发生概率极低，就算发生了也有解决方案。所以总体来说当前的发布流程可以满足大多数情况。

-----------------------

公众号：林老师带你学编程

网站：www.wolzq.com

代码无非增删改查，关注老师给你Coding

林老师带你学编程：http://www.wolzq.com