Git的原理和使用（六）

        本文主要讲解企业级开发模型

1. 引入

        交付软件的流程：开发->测试->发布上线

        上面三个过程可以详细划分为一下过程：规划、编码、构建、测试、发 布、部署和维护

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

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

        • 开发团队(尤其是敏捷团队)追求变化

         • 运维团队追求稳定

        双⽅往往存在利益的冲突。⽐如，精益和敏捷的团队把持续交付作为⽬标，⽽运维团队则为了线上的 稳定⽽强调变更控制。部⻔墙由此建⽴起来,这当然不利于 IT 价值的最⼤化 ；

        为了弥合开发和运维之间的鸿沟，需要在⽂化、⼯具和实践⽅⾯的系列变⾰⸺DevOps正式登上舞 台。

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

2. 系统开发环境

2.1 引入

        用户访问各种网页或者app，其实都是在访问部署的服务器（这些服务器上部署的都是稳定的代码），但是我们开发的代码不能直接放在这些服务器上；

        所以给开发人员开发专属于开发人员的服务器，这些服务器中只部署正在开发的代码，由此我们就会有环境隔离；

如下图所示：

        由上图所示，就有了发布环境和开发环境；

2.2 环境的分类

        对于开发⼈员来说，在系统开发过程中最常⽤的⼏个环境必须要了解⼀下：

        1. 开发环境：开发环境是程序猿们专⻔⽤于⽇常开发的服务器。为了开发调试⽅便，⼀般打开全部错 误报告和测试⼯具，是最基础的环境。

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

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

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

         这⼏个环境也可以说是系统开发的三个重要阶段：开发->测试->上线。⼀张图总结：

        生产集群的稳定是需要代码的稳定和环境配置；

 2.3 git分支设计

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

         git flow 模型：

2.3.1 master分支：

        • master 为主分⽀，该分⽀为只读且唯⼀分⽀。⽤于部署到正式发布环境，⼀般由合并 release （测试分支）分⽀得到。

        • 主分⽀作为稳定的唯⼀代码库,任何情况下不允许直接在 master 分⽀上修改代码。

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

        • master 分⽀不可删除。

2.3.2 feature分支

         • feature 分⽀通常为新功能或新特性开发分⽀，以 develop 分⽀为基础创建 feature 分 ⽀。

         • 命名以 feature/ 开头，建议的命名规则： feature/user_createtime_feature 。

         • 新特性或新功能开发完成后，开发⼈员需合到 develop 分⽀。

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

2.3.3 develop分支

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

         • 可根据需求⼤⼩程度确定是由 feature 分⽀合并，还是直接在上⾯开发（⾮常不建议）。

2.3.4 hotfix分支

         • hotfix 分⽀为线上 bug 修复分⽀或叫补丁分⽀，主要⽤于对线上的版本进⾏ bug 修复。当线上 出现紧急问题需要⻢上修复时，需要基于 master 分⽀创建 hotfix 分⽀。

         • 命名以 hotfix/ 开头，建议的命名规则: hotfix/user_createtime_hotfix

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

2.3.5 release 分⽀

        • release 为预发布分⽀，基于本次上线所有的 feature 分⽀合并到 develop 分⽀之后，基 于 develop 分⽀创建。可以部署到测试或预发布集群。

        • 命名以 release/ 开头，建议的命名规则: release/version_publishtime 。

         • release 分⽀主要⽤于提交给测试⼈员进⾏功能测试。发布提测阶段，会以 release 分⽀代码 为基准进⾏提测。

         • 如果在 release 分⽀测试出问题，需要回归验证 develop 分⽀看否存在此问题。

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

3. 企业级项目实战

3.1 准备工作

        Gitee企业版免费版

3.2 创建项⽬

3.3 创建仓库

3.4 添加成员 

此时我们的固有分支如下所示：

故此我们由于分支源于master建立的，所以删除这个项目，重新建立项目；

完成上述操作机删除原项目；

        我们本次的新建项目是生产开发者项目：

此后进行新建分支：

在新分支上修改文件并提交：

        如下我们的feature分支开发完成之后：

        将该分支合并到develop分支上去，进行请求评审，合并分支：

        此时f分支上完成功能需求，提交到dev分支上，这时候就需要测试人员来在realse分支上进行测试了，realse分支是基于develop分支上创建出来的，我们创建realse分支的时候要确保当前的dev分支上是最先进的内容文件：

        r分支创建之后，就会在该分支上添加测试环境来进行测试，测试通过之后我们会将r分支合并到master分支上，即发布上线操作；

        即来到r分支上发起pr：完成上述操作之后，我们的master就是当前最先进的内容了：

ps：关于git的所有学习就到这里了结束了，十分感谢又走过一个春秋的自己；

        祝好运！

        Good Luck!

-------------------------------

        上嘉路