6. 企业级Git分支模型实战指南
·
一.企业级开发模型 : 基本认识
我们知道，⼀个软件从零开始到最终交付，⼤概包括以下⼏个阶段：规划、编码、构建、测试、发
布、部署和维护。
最初，程序⽐较简单，⼯作量不⼤，程序员⼀个⼈可以完成所有阶段的⼯作。但随着软件产业的⽇益 发展壮⼤，软件的规模也在逐渐变得庞⼤。软件的复杂度不断攀升，⼀个⼈已经hold不住了，就开始出现了精细化分⼯。如下图所⽰： 
但在传统的 IT 组织下，开发团队(Dev)和运维团队(Ops)之间诉求不同：
- 开发团队(尤其是敏捷团队)追求变化
- 运维团队追求稳定
双⽅往往存在利益的冲突。⽐如，精益和敏捷的团队把持续交付作为⽬标，⽽运维团队则为了线上的 稳定⽽强调变更控制。部⻔墙由此建⽴起来,这当然不利于 IT 价值的最⼤化。
为了弥合开发和运维之间的鸿沟，需要在⽂化、⼯具和实践⽅⾯的系列变⾰⸺ DevOps 正式登上舞台。
DevOps（Development和Operations的组合词）是⼀种重视“软件开发⼈员（Dev）”和“IT运维技
术⼈员（Ops）”之间沟通合作的⽂化、运动或惯例。透过⾃动化“软件交付”和“架构变更”的流
程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。在DevOps的软件开发过程包含计划、编码、构建、测试、预发布、发布、运维、监控，由此可⻅DevOps的强⼤。
讲了这么多，这个故事到底和我们课程的主题 Git 有什么关系呢？
举⼀个很简单的例⼦就能说明这个问题。⼀个软件的迭代，在我们开发⼈员看来，说⽩了就是对代码进⾏迭代，那么就需要对代码进⾏管理。如何管理我们的代码呢，那不就是 Git（分布式版本控制系统） ！所以 Git 对于我们开发⼈员来说其重要性就不⾔⽽喻了
二.企业级分支模型核心
2.1 五大核心分支及其职责
| 分支类型 | 核心职责 | 适用环境 | 生命周期 |
|---|---|---|---|
| master | 存储可上线的稳定代码，唯一只读分支 | 生产环境 | 长期存在（不可删除） |
| develop | 聚合已完成的功能 / 修复代码，保持最新开发进度 | 开发环境 | 长期存在 |
| release/* | 预发布测试专用，基于 develop 创建 | 测试 / 预发布环境 | 临时分支（上线后可删除） |
| feature/* | 新功能 / 新特性开发，基于 develop 创建 | 本地 / 开发环境 | 临时分支（合并后可删除） |
| hotfix/* | 线上紧急 Bug 修复，基于 master 创建 | 生产 / 预发布环境 | 临时分支（修复后可删除） |
注：以上表格中的分⽀和环境的搭配仅是常⽤的⼀种，可视情况⽽定不同的策略。
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 分支并推送远程。一旦修复上线，便将其删除。
⼀张图总结： 
2.2 分支命名规范（企业实操版）
为了提高分支辨识度，企业中通常会约定统一的命名规则：
feature/[开发者]-[需求名]-[日期]：如feature/hyb-order-manage-20240520
release/[版本号]-[发布日期]：如release/v1.2.0-20240601
hotfix/[开发者]-[bug描述]-[日期]：如hotfix/hyb-login-error-20240605
三.环境与分支的绑定
| 序号 | 环境类型 | 说明与核心作用 |
|---|---|---|
| 1 | 开发环境 | 开发人员日常开发调试的服务器，会开启全部错误报告和测试工具，是最基础的环境。 |
| 2 | 测试环境 | 作为开发环境到生产环境的过渡，用于验证程序功能，若在此环境运行异常则不能发布到生产环境。 |
| 3 | 预发布环境 | 配置与生产环境基本一致，用于发现测试环境与线上环境差异导致的缺陷，是产品质量的最后一道防线。服务器为单独机器，不属于线上集成服务器范围。 |
| 4 | 生产环境 | 正式对外提供服务的线上环境，用户可直接访问，例如我们在移动端或 PC 端能访问到的 APP 都运行在这个环境中。 |
这⼏个环境也可以说是系统开发的三个重要阶段：开发->测试->上线。⼀张图总结
对于规模稍微⼤点的公司来说，可不⽌这么⼏个环境，⽐如项⽬正式上线前还存在仿真/灰度环境，再⽐如还存在多套测试环境，以满⾜不同版本上线前测试的需要。
⼀个项⽬的开始从设计开始，⽽⼀个项⽬的成功则从测试开始。⼀套良好的测试体系可以将系统中绝⼤部分的致命Bug 解决在系统上线之前。测试系统的完善和成熟也是衡量⼀个软件企业整体⽔平的重要指标之⼀，测试往往被忽视，因为它对可以的隐性、对软件开发企业不产⽣直接的效益，但是它却是软件质量的最终保障，乃⾄项⽬能否成功的重要因素
四.企业级项目管理实战
4.1 前置操作
- 准备工作：
DevOps研发平台 :Gitee企业版免费版,企业名称可随意填写⼀个,注意：多人协作开发，需要将多人账号拉入一下企业才行。如果添加成员后面会讲。
- 创建项目
- 创建仓库
注意:创建的仓库可以关联到某个项⽬中被管理
- 添加成员
1.添加企业成员
申请后需要负责⼈审批通过.
2.添加项目成员
3. 添加项目开发人员
4.2 开发场景-基于git flow模型的实践
- 新需求加入：现有一个订单管理的新需求需要开发，首先可以基于
develop分支创建一个feature/Milestone_order-20260113分支
- 需求在
feature/Milestone_order-20251116分支开发完毕，这时研发人员可以将代码合并到develop 分支，将其部署在开发环境的服务器中，方便开发人员进行测试和调试。
1.开发者在 feature 分支下请求评审
2. 审查员审查代码
3. 审查通过，合并分支
4. 合并成功，查看结果
- 在
develop下开发人员自测通过后，先确定下develop不存在未测试完毕的需求，然后研发人员可基于develop分支创建⼀个release/xxx分支出来，可交由测试人员进行测试。
测试人员测试 release 通过后（包含测试环境和预发布环境的测试），就可将代码合并入 master
- 测试人员在
master(正式环境) 测试通过后，便可删除feature/xxx分支。
4.3补充
- 修复测试环境 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 分⽀
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
10
0- 0
已为社区贡献5条内容
所有评论(0)