点赞👍👍收藏🌟🌟关注💖💖
你的支持是对我最大的鼓励，我们一起努力吧!😃😃

1.企业级开发流程

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

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

软件开发工程师(开发团队)职责就是写写写，软件测试工程师(测试团队)职责就是测测测，软件运维工程师(运维团队)职责就是稳稳稳。

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

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

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

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

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

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

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

2.系统开发环境

对于我们日常生活中用户来说我们想要访问手机的app其实就是一些服务器，这些服务器上面部署的都是稳定的代码，所以用户可以顺畅的体验app。对于开发人员来说我们不能将自己开发的代码直接部署到用户能访问到的服务器上，因为可能会存在bug从而导致用户体验感变差。

如何解决呢？我们可以给开发人员在去创建一批属于他们自己开发的服务器，这些服务器专门部署正在开发的代码。和用户访问到的服务器互不影响，由此我们就有了环境隔离的概念。

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

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

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

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

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

3.Git 分支设计规范

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

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

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

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 分支设计规范：Git Flow 模型。但要说的是，该模型并不是适用于所有的团队、所有的环境和所有的文化。如果你采用了持续交付，你会想要一些能够尽可能简化交付过程的东西。有些人喜欢基于主干的开发模式，喜欢使用特性标志。然而，从测试的角度来看，这些反而会把他吓一跳。

关键在于站在你的团队或项目的角度思考：这种分支模型可以帮助你们解决哪些问题？它会带来哪些问题？这种模式为哪种开发提供更好的支持？你们想要鼓励这种行为吗？你选择的分支模型最终都是为了让人们更容易地进行软件协作开发。因此，分支模型需要考虑到使用者的需求，而不是盲目听信某些所谓的“成功的分支模型”。

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

4.企业级项目管理实战

4.1准备工作

DevOps研发平台 Gitee企业版免费版

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

4.2创建项目

4.4创建仓库

这样就创建出一个属于项目中的一个仓库

4.5添加成员

项目肯定是多人协作开发的，我们必须要先给企业添加成员。

1.企业添加成员

申请后需要负责人审批通过。

然后在给项目添加成员

项目添加成员

添加仓库开发人员

仓库添加人员

到此我们的准备工作就完成了，下面就开始进行开发了。

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

比如说现在仓库需要增加一个支付的功能，首先可以基于 develop 分支创建⼀个
feature/dl_20240920_pay 分支。

然后我们就可以把这个feature分支拉到本地进行代码的开发，开发完之后在把本地的修改push到远端feature分支，这套流程之前我们已经说了。

这里我们简单一点就在远端feature分支修改个README.md文件，然后合并。

1. 需求在 feature/dl_20240920_pay 分支开发完毕，这时开发人员可以将代码合并到develop 分支，将其部署在开发环境的服务器中，方便开发人员进行测试和调试。

开发者在 feature 分支下发起请求评审

审查员审查代码

2. 审查通过，合并分支

合并成功，然后我们就能在develop分支看到最新的代码

3. 在 develop 下开发人员自测通过后，先确定下 develop 不存在未测试完毕的需求，然后研发人员可基于 develop 分支创建⼀个 release/xxx 分支出来，可交由测试⼈员进行测试

4. 测试人员测试 release 通过后（包含测试环境和预发布环境的测试），就可将代码合并入master

现在master分支上已经就有最新最稳的代码了。然后就可以把没用的分支删掉了。

这里我们没有演示怎么部署，它是付费的。感兴趣的可以自己尝试。

修复测试环境 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 分支。

拓展阅读

其他DevOps研发平台

腾讯coding
阿里云效

拓展实践

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