Git Flow 的正确使用姿势

一、背景：

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

测试环境
线上环境
release环境
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 正常发布流程

根据产品需求，以master为源代码创建feature branches，命名规范为：feature_产品版本号-需求说明。
feature branches开发自测完毕之后，合并到dev分支等待测试人员测试。
测试人员测试通过之后，通知分支开发负责人将需求发布到预发布环境。
开发人员将feature branches代码合并到release branches中，等待发布上线。
得到允许发布到线上的命令之后，将release branches代码合并到master分支，并打上tag记录。
将上线版本对应的feature branches删除。

4.6 bug修复流程

出现bug之后，以release branches为源码创建hotfixes分支，命名规范为hotfixes_负责人_bug说明。
hotfixes分支开发自测通过之后，修改bug环境对应服务的分支指向，启动完毕之后通知测试人员开始测试。
测试人员测试通过之后，通过对应开发人员。
开发人员收到通知后，就可以将hotfixes分支代码合并到release branches和erp-dev分支中，并修改回bug环境对应服务的分支配置（默认为release分支）。
release分支功能发布线上之后（bug修复的代码包含在里面），将对应的bug分支删除。

4.7 版本发布流程图

五、demo流程演示

5.1 正常发布流程

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

现要求：

代码语言：javascript复制

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版本代码。