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分支为源头创建如下分支：

现要求：

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 Flow 的正确使用姿势相关推荐

如何正确使用Git Flow 流程
我们已经从SVN 切换到Git很多年了,现在几乎所有的项目都在使用Github管理, 本篇文章讲一下为什么使用Git, 以及如何在团队中正确使用. Git的优点 Git的优点很多,但是这里只列出我认为 ...
Git 在团队中的最佳实践--如何正确使用Git Flow
我们已经从SVN 切换到Git很多年了,现在几乎所有的项目都在使用Github管理, 本篇文章讲一下为什么使用Git, 以及如何在团队中正确使用. Git的优点 Git的优点很多,但是这里只列出我认为 ...
Git，Git Flow，GitLab使用指南
高效利用一次蹲坑时间,看看如何使用Git Flow进行高效开发,什么才是Git提交的正确姿势,怎样使用GitLab进行Code Review: 使用Git Flow高效开发: Git提交正确姿势,Co ...
持续交付之基于Git Flow代码分支策略实践
文章目录一.前言二.主干开发(TBD) 三.特性开发 1.Git Flow 2.产品分支策略 2.1.基本情况 2.2.分支管理 2.3.分支合并时间 2.4.初始化配置 2.5.迭代开发 2.6 ...
SAP Spartacus 的 git flow 和发布流程
Git Flow and Release Process Library Version Compatibility Spartacus 项目由一组库组成. 为了更容易知道哪个版本的库与另一个版本兼容 ...
为什么我从 Git Flow 开发模式切换到了 Trunk Based 开发模式？
我已经使用 Git Flow 构建我的 Git 分支有几年了.但是,我遇到了 Git Flow 的一些问题,其中大部分来自长期存在的分支.解决这些问题的方案就是 Trunk Based Develop ...
Git Flow 分支管理简述
概述 Git 是什么 Git 是一个开源的分布式版本控制系统,用于敏捷高效地处理任何或小或大的项目. Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的 ...
babun 如何安装git flow 以及使用
推荐使用: windows环境: https://github.com/babun/babun linux 随意了 Git 在团队中的最佳实践--如何正确使用Git Flow 2018-10-14 0 ...
Git Flow—Git团队协作最佳实践
一.规范的Git使用 Git是一个很好的版本管理工具,不过相比于传统的版本管理工具,学习成本比较高. 实际开发中,如果团队成员比较多,开发迭代频繁,对Git的应用比较混乱,会产生很多不必要的冲突或者代 ...

Git Flow 的正确使用姿势

Git Flow 的正确使用姿势相关推荐

最新文章

热门文章