标签：姿势 Git branches Flow feature master release bug 分支

一、背景：

大多数公司为了可以快速迭代，一般只有两个环境，一个是测试环境，另外一个是线上环境。这个时候问题就来了，如果线上出现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 

标签：姿势,Git,branches,Flow,feature,master,release,bug,分支
来源： https://blog.csdn.net/linzhiqiang0316/article/details/116503634

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。