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 分支作为测试环境对应服务分支，测试通过之后，将 ho

【一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义】
浏览器打开：qq.cn.hn/FTf 免费领取

tfixes_linzhiqiang_login 合并到 release 分支中，等待发布上线。

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

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

5.3 注意事项