Git--项目开发模型

一、系统开发环境

1.开发环境:开发环境是程序猿们专⻔⽤于⽇常开发的服务器。为了开发调试⽅便,⼀般打开全部错
误报告和测试⼯具,是最基础的环境。
2.测试环境:⼀个程序在测试环境⼯作不正常,那么肯定不能把它发布到⽣产机上。该环境是开发环
境到⽣产环境的过渡环境。
3.预发布环境:该环境是为避免因测试环境和线上环境的差异等带来的缺陷漏测⽽设⽴的⼀套环境。其配置等基本和⽣产环境⼀致,⽬的是能让我们发正式环境时更有把握!所以预发布环境是你的产品质量最后⼀道防线,因为下⼀步你的项⽬就要上线了。要注意预发布环境服务器不在线上集成服务器范围之内,为单独的⼀些机器。
4.生产环境:是指正式提供对外服务的线上环境,例如我们⽬前在移动端或PC端能访问到的APP都是⽣产环境。
这⼏个环境也可以说是系统开发的三个重要阶段:开发->测试->上线。⼀张图总结:
在这里插入图片描述

二、Git分支设计规范

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

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

2.1 master分支

1.master 为主分⽀,该分⽀为只读且唯⼀分⽀。⽤于部署到正式发布环境,⼀般由合并release分⽀得到。
2.主分⽀作为稳定的唯⼀代码库,任何情况下不允许直接在master分⽀上修改代码。
3.产品的功能全部实现后,最终在master分⽀对外发布,另外所有在master分⽀的推送应该打标签(tag)做记录,⽅便追溯。
4.master分⽀不可删除。

2.2 release分支

1.release 为预发布分⽀,基于本次上线所有的 feature 分⽀合并到 develop 分⽀之后,基于develop 分⽀创建。可以部署到测试或预发布集群。
2.命名以release/ 开头,建议的命名规则: release/version_publishtime 。
3. release 分⽀主要⽤于提交给测试⼈员进⾏功能测试。发布提测阶段,会以 release 分⽀代码为基准进⾏提测。
4.如果在 release 分⽀测试出问题,需要回归验证 develop 分⽀看否存在此问题。
5.release 分⽀属于临时分⽀,产品上线后可选删除。

2.3 develop分支

1.develop 为开发分⽀,基于master分⽀创建的只读且唯⼀分⽀,始终保持最新完成以及bug修复后的码。可部署到开发环境对应集群。
2.可根据需求⼤⼩程度确定是由 feature 分⽀合并,还是直接在上⾯开发(⾮常不建议)。

2.4 feature分支

1.feature 分⽀通常为新功能或新特性开发分⽀,以 develop 分⽀为基础创建 feature 分支。
2.命名以 feature/ 开头,建议的命名规则: feature/user_createtime_feature 。
3.新特性或新功能开发完成后,开发⼈员需合到 develop 分⽀。
4.⼀旦该需求发布上线,便将其删除。

2.5 hotfix分支

1.hotfix 分⽀为线上bug修复分⽀或叫补丁分⽀,主要⽤于对线上的版本进⾏bug修复。当线上出现紧急问题需要⻢上修复时,需要基于 master 分⽀创建 hotfix 分⽀。
2.命名以 hotfix/ 开头,建议的命名规则: hotfix/user_createtime_hotfix
3.当问题修复完成后,需要合并到 master 分⽀和 develop 分⽀并推送远程。⼀旦修复上线,便将其删除。
在这里插入图片描述
  其实,以上是常⽤的⼀种Git分⽀设计规范:Git Flow模型。

三、项目管理实战

  准备工作:DevOps研发平台。Gitee企业版免费版
在这里插入图片描述
  企业名称可随意填写⼀个测试名称,只要能通过即可。注意,多⼈协作开发,需要将多⼈账号拉⼊⼀个企业下才⾏。

3.1 创建项目

在这里插入图片描述

在这里插入图片描述
在这里插入图片描述

3.1 创建仓库

在这里插入图片描述
在这里插入图片描述
:创建的仓库可以关联到某个项⽬中被管理

3.2 添加成员

  1. 添加企业成员
    在这里插入图片描述
    在这里插入图片描述
  2. 添加项⽬成员
    在这里插入图片描述
    在这里插入图片描述
  3. 添加仓库开发⼈员
    在这里插入图片描述
    在这里插入图片描述

四、开发场景-基于git flow模型德实践

4.1 新需求加⼊

  现有⼀个订单管理的新需求需要开发,⾸先可以基于 develop 分⽀创建⼀个feature/zl_order_20231012 分⽀。
在这里插入图片描述
在这里插入图片描述
1.需求在 feature/zl_order_20231012 分⽀开发完毕,这时研发⼈员可以将代码合并到develop 分⽀,将其部署在开发环境的服务器中,⽅便开发⼈员进⾏测试和调试。
  a. 开发者在 feature 分⽀下发起请求评审

在这里插入图片描述
在这里插入图片描述
  b. 审查员审查代码
在这里插入图片描述
  c. 审查通过,合并分⽀
在这里插入图片描述  d. 合并成功,查看结果
在这里插入图片描述
2. 在develop 下开发⼈员⾃测通过后,先确定下 develop 不存在未测试完毕的需求,然后研发⼈员可基于 develop 分⽀创建⼀个 release/xxx 分⽀出来,可交由测试⼈员进⾏测试。
在这里插入图片描述
3. 测试⼈员测试 release 通过后(包含测试环境和预发布环境的测试),就可将代码合并⼊master 。
在这里插入图片描述
在这里插入图片描述
4. 测试⼈员在 master (正式环境)测试通过后,便可删除 feature/xxx 分⽀。
在这里插入图片描述

五、Bug的修改

5.1 修复测试环境Bug

  在develop 测试出现了Bug,建议⼤家直接在 feature 分⽀上进⾏修复。修复后的提测上线流程与新需求加⼊的流程⼀致。

5.2 修改预发布环境Bug

  在 release 测试出现了Bug,⾸先要回归下 develop 分⽀是否同样存在这个问题。如果存在,修复流程与修复测试环境Bug流程⼀致。
  如果不存在,这种可能性⽐较少,⼤部分是数据兼容问题,环境配置问题等。

5.3 修改正式环境Bug

  在 master 测试出现了Bug,⾸先要回归下 release 和 develop 分⽀是否同样存在这个问题。
  如果存在,修复流程与修复测试环境Bug流程⼀致。
  如果不存在,这种可能性也⽐较少,⼤部分是数据兼容问题,环境配置问题等。

5.4 紧急修复正式环境Bug

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

  • 29
    点赞
  • 25
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值