【Git原理与使用】-- 企业级开发模型

目录

引入

系统开发环境

Git 分支设计规范

master 分支

release 分支

develop 分支

feature 分支

hotfix 分支

开发场景 - 基于git flow模型的实践

DevOps研发平台

修复测试环境 Bug

修改预发布环境 Bug

修改正式环境 Bug

紧急修复正式环境 Bug

拓展实践

---

都说：对于开发者，Git是非常的重要的，但是为什么呢？这就需要从企业级的开发流程来说。

引入

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

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

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

• 开发团队：(尤其是敏捷团队)追求变化。
• 运维团队：追求稳定。

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

        为了弥合开发和运维之间的鸿沟，需要在文化、工具和实践方面的系列变革 ⸺ DevOps正式登上舞台。

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

DevOps到底是什么意思？

        与Git的关系， 举个例子：⼀个软件的迭代，在我们开发人员看来，说白了就是对代码进行迭代，那么就需要对代码进行管理。也就是 Git（分布式版本控制系统），所以 Git 对于我们开发⼈员来说其重要性就不⾔而喻了。

系统开发环境

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

1. 开发环境：开发环境是程序猿们专门用于日常开发的服务器。为了开发调试方便，⼀般打开全部错误报告和测试工具，是最基础的环境。
2. 测试环境：⼀个程序在测试环境工作不正常，那么肯定不能把它发布到生产机上。该环境是开发环境到生产环境的过渡环境。
3. 预发布环境：该环境是为避免因测试环境和线上环境的差异等带来的缺陷漏测而设立的⼀套环境。其配置等基本和⽣产环境⼀致，⽬的是能让我们发正式环境时更有把握！所以预发布环境是你的产品质量最后⼀道防线，因为下⼀步你的项⽬就要上线了。要注意预发布环境服务器不在线上集成服务器范围之内，为单独的⼀些机器。
4. 生产环境：是指正式提供对外服务的线上环境，例如我们目前在移动端或PC端能访问到的APP都是生产环境。

        这几个环境也可以说是系统开发的三个重要阶段：开发->测试->上线。

        对于规模稍微大点的公司来说，可不止这么几个环境，比如项目正式上线前还存在仿真 / 灰度环境（利用部分相对少量的用户来测试），再比如还存在多套测试环境，以满足不同版本上线前测试的需要。

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

Git 分支设计规范

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

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

注： 以上表格中的分支和环境的搭配仅是常用的⼀种，可视情况而定不同的策略。

        以上跟大家讲解的是企业级常用的⼀种 Git 分支设计规范：Git Flow 模型。 

master 分支

        master 为主分支，该分支为只读且唯一分支。用于部署到正式发布环境，⼀般由合并 release 分支得到。主分支作为稳定的唯⼀代码库，任何情况下不允许直接在 master 分支上修改代码。产品的功能全部实现后，最终在 master 分支对外发布，另外所有在 master 分支的推送应该打标签（tag）做记录，方便追溯。

        master 分支不可删除。

release 分支

        release 为预发布分支，基于本次上线所有的 feature 分支合并到 develop 分支之后，基于 develop 分支创建。可以部署到测试或预发布集群。命名以 release/ 开头，建议的命名规则: release/version_publishtime 。release 分支主要用于提交给测试人员进行功能测试。发布提测阶段，会以 release 分支代码为基准进行提测。如果在 release 分支测试出问题，需要回归验证 develop 分支看否存在此问题。

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

develop 分支

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

         可根据需求大小程度确定是由 feature 分支合并。

feature 分支

        feature 分支通常为新功能或新特性开发分支，以 develop 分支为基础创建 feature 分支。命名以 feature/ 开头，建议的命名规则： feature/user_createtime_feature 。新特性或新功能开发完成后，开发人员需合到 develop 分支。

        一旦该需求发布上线，便将其删除。

hotfix 分支

        hotfix 分支为线上 bug 修复分支或叫补丁分支，主要用于对线上的版本进行 bug 修复。当线上出现紧急问题需要马上修复时，需要基于 master 分支创建 hotfix 分支。命名以 hotfix/ 开头，建议的命名规则: hotfix/user_createtime_hotfix 。

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

开发场景 - 基于git flow模型的实践

DevOps研发平台

腾讯

阿里云

gitee

修复测试环境 Bug

        在 develop 测试出现了Bug，建议直接在 feature 分支 上进行修复。修复后的提测上线流程与 新需求加入的流程⼀致。

修改预发布环境 Bug

在 release 测试出现了 Bug，首先要回归下 develop 分支 是否同样存在这个问题。

• 如果存在，修复流程与修复测试环境 Bug 流程⼀致。
• 如果不存在，这种可能性比较少，大部分是数据兼容问题，环境配置问题等。

修改正式环境 Bug

在 master 测试出现了Bug，首先要回归下 release 和 develop 分支 是否同样存在这个问题。

• 如果存在，修复流程与修复测试环境 Bug 流程⼀致。
• 如果不存在，这种可能性也比较少，大部分是数据兼容问题，环境配置问题等。

紧急修复正式环境 Bug

        需求在测试环节未测试出 Bug，上线运行⼀段时候后出现了 Bug，需要紧急修复的。有的企业面对紧急修复时，支持不进行测试环境的验证，但还是建议验证下预发布环境。可基于 master 创建 hotfix/xxx 分支 ，修复完毕后发布到 master 验证，验证完毕后，将 master 代码合并到 develop 分支 ，同时删掉 hotfix/xxx 分支 。

拓展实践

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