【Git：企业级开发模型】Git企业级Git工作流实战：基于Git Flow的分支模型与开发流程

🔥艾莉丝努力练剑：个人主页

❄专栏传送门：《C语言》、《数据结构与算法》、C/C++干货分享&学习过程记录、Linux操作系统编程详解、笔试/面试常见算法：从基础到进阶、测试开发要点全知道

⭐️为天地立心，为生民立命，为往圣继绝学，为万世开太平

🎬艾莉丝的简介：

前情提示

[1 系统开发过程中最常用的几个环境](#1 系统开发过程中最常用的几个环境)

[2 Git分支设计模型：五大分支图解](#2 Git分支设计模型：五大分支图解)

[3 Bug修复](#3 Bug修复)

[4 拓展阅读](#4 拓展阅读)

其他DevOps研发平台

拓展实践

艾莉丝的Gitee地址

[1 ~> 企业级开发流程](#1 ~> 企业级开发流程)

[2 ~> 系统开发模型](#2 ~> 系统开发模型)

[3 ~> Git分支设计模型（Git Flow模型）](#3 ~> Git分支设计模型（Git Flow模型）)

[3.1 分支和环境的搭配（仅供参考）](#3.1 分支和环境的搭配（仅供参考）)

[3.2 五大分支](#3.2 五大分支)

[3.2.1 master分支](#3.2.1 master分支)

[3.2.2 release分支](#3.2.2 release分支)

[3.2.3 develop分支](#3.2.3 develop分支)

[3.2.4 feature分支](#3.2.4 feature分支)

[3.2.5 hotfix分支](#3.2.5 hotfix分支)

[3.2.6 总结](#3.2.6 总结)

[3.3 企业级常用的一种Git分支设计规范：Git Flow模型](#3.3 企业级常用的一种Git分支设计规范：Git Flow模型)

[4 ~> 企业级项目管理：准备工作](#4 ~> 企业级项目管理：准备工作)

[4.1 DevOps研发平台](#4.1 DevOps研发平台)

[4.2 创建项目](#4.2 创建项目)

[4.3 新建仓库](#4.3 新建仓库)

[4.4 添加成员](#4.4 添加成员)

[4.4.1 添加企业成员：链接邀请](#4.4.1 添加企业成员：链接邀请)

[4.4.2 添加企业成员：邮件邀请](#4.4.2 添加企业成员：邮件邀请)

[4.4.3 添加项目成员](#4.4.3 添加项目成员)

[4.4.4 项目成员添加完之后：添加仓库开发人员](#4.4.4 项目成员添加完之后：添加仓库开发人员)

[4.4.4.1 添加方式1](#4.4.4.1 添加方式1)

[4.4.4.2 添加方式2](#4.4.4.2 添加方式2)

[5 ~> 企业级项目管理：开发场景实操（基于git flow模型的实践）](#5 ~> 企业级项目管理：开发场景实操（基于git flow模型的实践）)

[5.1 新需求加入](#5.1 新需求加入)

[5.1.1 将代码合并并部署到开发环境的服务器中：方便开发人员进行测试和调试](#5.1.1 将代码合并并部署到开发环境的服务器中：方便开发人员进行测试和调试)

[5.1.1.1 开发者在feature分支下发起请求评审](#5.1.1.1 开发者在feature分支下发起请求评审)

[5.1.1.2 审查员审查代码](#5.1.1.2 审查员审查代码)

[5.1.1.3 审查通过，合并分支](#5.1.1.3 审查通过，合并分支)

[5.1.1.4 合并成功，查看结果](#5.1.1.4 合并成功，查看结果)

[5.1.2 交由测试人员进行测试](#5.1.2 交由测试人员进行测试)

[5.1.3 测试release通过后将代码合并入master](#5.1.3 测试release通过后将代码合并入master)

[5.1.4 测试通过后，便可删除feature/xxx分值](#5.1.4 测试通过后，便可删除feature/xxx分值)

[5.2 修复Bug](#5.2 修复Bug)

[5.2.1 修复测试环境Bug](#5.2.1 修复测试环境Bug)

[5.2.2 修改预发布环境Bug](#5.2.2 修改预发布环境Bug)

[5.2.3 修改正式环境Bug](#5.2.3 修改正式环境Bug)

[5.2.4 紧急修复正式环境Bug](#5.2.4 紧急修复正式环境Bug)

Git：企业级开发模型部分博主手记

[1 企业级开发流程](#1 企业级开发流程)

[2 系统开发模型](#2 系统开发模型)

[3 Git分支设计模型](#3 Git分支设计模型)

[4 企业级项目管理：准备工作](#4 企业级项目管理：准备工作)

[5 企业级项目管理：开发场景实操](#5 企业级项目管理：开发场景实操)

结尾

前情提示

本文是艾莉丝Git博客的最后一篇，不知道艾莉丝的博客是否有帮到您呢

1 系统开发过程中最常用的几个环境

2 Git分支设计模型：五大分支图解

3 Bug修复

4 拓展阅读

其他DevOps研发平台

腾讯coding、阿里云云效

拓展实践

阿里飞流flow分支模型，及项目版本管理实践：

项目版本管理的最佳实践：飞流Flow（阿里AoneFlow）篇

艾莉丝的Gitee地址

艾莉丝努力练剑的Gitee

1 ~> 企业级开发流程

我们通过一个小故事来切入到今天的正题。

我们知道：一个软件从零开始到最终交付，大概包括了以下几个阶段：规划、编码、构建、测试、发布、部署和维护。

最初，程序比较简单，工作量不大，程序员一个人可以完成所有阶段的工作；但随着软件产业的日益发展壮大，软件的规模也在逐渐变得庞大。软件的复杂度不断攀升，一个人已经hold不住了，就开始出现了精细化分工。如下图所示：

在传统的IT组织下，开发团队 (Dev) 和运维团队 (Ops) 之间诉求不同：

双方往往存在利益的冲突。比如，精益和敏捷的团队把持续交付作为目标，而运维团队则为了线上的稳定而强调变更控制。部门墙由此建立起来，这当然不利于IT价值的最大化。

为了弥合开发和运维之间的鸿沟（目的），需要在文化、工具和实践方面的系列变革------DevOps（给大家推荐一篇知乎大佬的介绍DevOps的文章）正式登上舞台。

DevOps（Development和Operations的组合词）是一种重视"软件开发人员 (Dev) "和"IT运维技术人员 (Ops) "之间沟通合作的文化、运动或惯例。透过自动化"软件交付"和"架构变更"的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。在DevOps的软件开发过程包含计划、编码、构建、测试、预发布、发布、运维、监控，由此可见DevOps的强大。

讲了这么多，这个故事到底和我们本专栏的主题Git有什么关系呢？

举一个很简单的例子就能说明这个问题。一个软件的迭代，在开发人员看来，说白了就是对代码进行迭代，那么就需要对代码进行管理。如何管理我们的代码呢，那不就是Git（分布式版本控制系统）！Git对于我们开发人员来说其重要性就不言而喻了。

2 ~> 系统开发模型

言归正传，对于开发人员来说，在系统开发过程中最常用的几个环境必须要了解一下：

1、开发环境：开发环境是程序猿们专门用于日常开发的服务器。为了开发调试方便，一般打开全部错误报告和测试工具，是最基础的环境。

2、测试环境：一个程序在测试环境工作不正常，那么肯定不能把它发布到生产机上。该环境是开发环境到生产环境的过渡环境。

3、预发布环境：该环境是为避免因测试环境和线上环境的差异等带来的缺陷漏测而设立的一套环境。其配置等基本和生产环境一致，目的是能让我们发正式环境时更有把握！所以预发布环境是你的产品质量最后一道防线，因为下一步你的项目就要上线了。要注意预发布环境服务器不在线上集成服务器范围之内，是单独的一些机器。

4、生产环境：是指正式提供对外服务的线上环境，例如我们目前在移动端或PC端能访问到的APP都是生产环境。

这几个环境也可以说是**系统开发的三个重要阶段：**开发 ~> 测试 ~> 上线，用一张图进行总结：

对于规模稍微大点的公司来说可不止这么几个环境，比如项目正式上线前还存在仿真 / 灰度环境（灰度机器，有策略：让某个地区的人先来访问，比如北京、上海...... ~> 让用户帮我们测试） ，如果这个地区的用户使用起来感觉没有问题，再推向全国------地域灰度策略，还有人群灰度策略：比如某个群体，可以是青少年、老年人、女性等等，如下图所示------

再比如还存在多套测试环境，以满足不同版本上线前测试的需要。

一个项目的开始从设计开始，而一个项目的成功则从测试开始。一套良好的测试体系可以将系统中绝大部分的致命Bug解决在系统上线之前。测试系统的完善和成熟也是衡量一个软件企业整体水平的重要指标之一，测试往往被忽视，因为它对可以的隐性、对软件开发企业不产生直接的效益，但是它却是软件质量的最终保障，乃至项目能否成功的重要因素！

3 ~> Git分支设计模型（Git Flow模型）

3.1 分支和环境的搭配（仅供参考）

环境有了概念后，那么对于开发人员来说，一般会针对不同的环境来设计分支，例如：

分支	名称	适用环境
master	主分支	生产环境
release	预发布分支	预发布/测试环境
develop	开发分支	开发环境
feature	需求开发分支	本地
hotfix	紧急修复分支	本地

**注意：**表格中的分支和环境的搭配仅是常用的一种，可视情况而定不同的策略，仅供参考。

3.2 五大分支

3.2.1 master分支

（1）master为主分支，该分支为只读且唯一分支。用于部署到正式发布环境，一般由合并release分支得到；

（2）主分支作为稳定的唯一代码库，任何情况下不允许直接在master分支上修改代码；

（3）产品的功能全部实现后，最终在master分支对外发布，另外所有在master分支的推送应该打标签（tag）做记录------方便追溯；

（4）master分支不可删除。

3.2.2 release分支

（1）release为预发布分支，基于本次上线所有的feature分支合并到develop分支之后，基于develop分支创建（最新、最全的develop分支）------可以部署到测试或预发布集群；

（2）命名以release/开头，建议的命名规则：release/version_publishtime；

（3）release分支主要用于提交给测试人员进行功能测试。发布提测阶段，会以release分支代码为基准进行提测；

（4）如果在release分支测试出问题，需要回归验证develop分支看否存在此问题；

（5）release分支属于临时分支，产品上线后可选删除。

3.2.3 develop分支

（1）develop为开发分支，基于master分支创建的只读且唯一分支，始终保持最新完成以及bug修复后的代码------可部署到开发环境对应集群；

（2）可根据需求大小程度确定是由feature分支合并、还是直接在上面开发 (非常不建议) 。

3.2.4 feature分支

（1）feature分支通常为新功能或新特性开发分支，以develop分支为基础创建feature分支；

（2）命名以feature/开头，建议的命名规则：feature/user_createtime_feature；

（3）新特性或新功能开发完成后，开发人员需将其合并到develop分支；

（4）一旦该需求发布上线便将其删除。

3.2.5 hotfix分支

（1）hotfix分支为线上bug修复分支或叫补丁分支，主要用于对线上的版本进行bug修复。**当线上出现紧急问题需要马上修复时，**需要基于master分支创建hotfix分支；

（2）命名以hotfix/开头，建议的命名规则:hotfix/user_createtime_hotfix；

（3）当问题修复完成后，需要合并到master分支和develop分支并推送远程。一旦修复上线，便将其删除。

3.2.6 总结

我们用一张图总结一下上面五种分支之间的关系------

3.3 企业级常用的一种Git分支设计规范：Git Flow模型

其实，上面跟uu们讲解的是企业级常用的一种Git分支设计规范：**GitFlow模型。但要说的是，该模型并不是适用于所有的团队、所有的环境和所有的文化**。如果你采用了持续交付（部署），你会想要一些能够尽可能简化交付过程的东西。有些人喜欢基于主干的开发模式****（只有master分支和feature分支，feature分支上面开发，直接合并到master分支上面），喜欢使用特性标志。然而，从测试的角度来看，这些反而会把他吓一跳。

关键在于站在你的团队或项目的角度思考：这种分支模型可以帮助你们解决哪些问题？它会带来哪些问题？这种模式为哪种开发提供更好的支持？你们想要鼓励这种行为吗？

你选择的分支模型最终都是为了让人们更容易地进行软件协作开发。因此，分支模型需要考虑到使用者的需求，**而不是盲目听信某些所谓的"成功的分支模型"，**不存在成功的，只有适合的。

所以对于不同公司，规范是会有些许差异，但万变不离其宗，是为了效率与稳定。

4 ~> 企业级项目管理：准备工作

4.1 DevOps研发平台

Gitee企业版（免费版）

企业名称可随意填写一个测试名称，只要能通过即可。注意，多人协作开发，需要将多人账号拉入一个企业下才行。如何添加成员后面会跟uu们讲解。

因为是Gitee企业级免费版平台，所以只能容纳5个人之内的协作。

4.2 创建项目

4.3 新建仓库

企业、项目、仓库之间的关系简易图：

之所以推荐【生产/开发模型（支持master / develop 类型分支)】是因为master和develop这两个分支都是只读且唯一的，其它的分支可能有多个，我们将来需要手动创建，所以不要去选，选了会有什么问题？举个例子：比如你创建仓库时选了【开发/发布/缺陷分离模型(支持 master / develop / feature / release / hotfix 类型分支) 】，那么就相当于默认初始化了这几个分支，并且由于已经默认初始化了，会不允许创建同名分支------一旦创建就会告知创建失败！