前言
🍊缘由
Git分支管理好,走到哪里都是宝
🏀事情起因:
最近翻看博客中小伙伴评论时,发现文章【规范】看看人家Git提交描述,那叫一个规矩一条回复:
本狗亲测在我司中使用规范的好处 ,遂把我司的Git分支管理规范 跟大家分享下,可能与大厂标准流程有些简化区别,望大厂大佬勿喷
🎯主要目标
实现3大重点
1. 为什么要制定Git分支管理规范
2. 我司Git分支都有哪些
3. Git分支在实际开发中使用流程
正文
🥦目标分析
1.为什么要制定Git分支管理规范?
-
加速团队协作,让成员明确各分支用途。
-
确保代码质量,通过审查保证稳定性和高质量。
-
维护主分支稳定,避免未完成代码干扰生产环境。
-
支持敏捷开发,适应快速迭代和持续集成。
-
便于问题解决,快速定位错误来源。
-
新人快速上手,标准化流程易于理解。
-
促进代码复用,鼓励模块化开发。
2.我司Git分支都有哪些?
主分支:
主干分支具有分支保护权限,只有运维有权限进行合并分支
| 分支模型 | 用途 | |---------|-------------------| | master | 主干分支,正式版本代码归档 | | develop | 开发分支,团队成员日常开发的主分支 | | doc | 文档分支,SQL脚本、配置等 |
辅助分支:
属于临时分支,当功能合并主干后,会删除清理掉
| 分支模型 | 用途 | |---------|-------------------| | feature | 从develop拉取开发的功能分支 | | hotfix | bug修复分支 |
3.Git分支在实际开发中使用流程
举个例子🌰
2024年7月3日,我司敏捷团队进行任务分解后,javadog项目正式开启新的迭代,版本号为v2.1.1
一. 开发前,通过develop分支拉取功能分支
✅有什么好处?
保持团队的起始开发分支一致,从同一个起点出发
通过develop中拉取新分支:feature-javadog-v2.1.1-SNAPSHOT-20240703
记住!记住!记住!这个feature-javadog-v2.1.1-SNAPSHOT-20240703 叫功能分支
开发环境中,自动化部署都是通过这个分支名进行打包,命名解释如下:
二. 开发中,各个组员根据功能分支拉取自己临时开发分支
✅有什么好处?
团队成员有自己临时开发分支,保证开发灵活性,提测版本稳定性,保证功能分支的健壮稳定性
- 通过功能分支 feature-javadog-v2.1.1-SNAPSHOT-20240703,拉取对应团队组员自己开发分支
👦张三 拉取自己开发临时功能分支:feature-javadog-v2.1.1-SNAPSHOT-20240703-zhangsan
🧔李四 拉取自己开发临时功能分支:feature-javadog-v2.1.1-SNAPSHOT-20240703-lisi
三. 提测中,各个组员将自己临时开发分支合并到功能分支进行流水线打包提测
✅有什么好处?
团队成员每完成自己任务并验证后,即可合并提测,提高合作效率,加快提测速度,推进项目进度有序进行
张三开发的模块A功能完成,本地调试正常后,将自己临时分支合并到功能分支 ,流水线由测试小姐姐打包功能分支feature-javadog-v2.1.1-SNAPSHOT-20240703
四. 开发环境测试结束,从功能开发分支拉出去掉快照标识的预生产分支
✅有什么好处?
保证功能分支灵活性,并兼顾预生产版本分支,如预生产环境遇到问题,可以在功能分支修复并在开发环境验证,解耦保持稳定性
通过功能分支 feature-javadog-v2.1.1-SNAPSHOT-20240703,拉取feature-javadog-v2.1.1-20240703 预生产分支,并打出对应tag,然后发布预生产
五. 预生产稳定后,将蓝绿部署平衡切换正式,然后逐个将分支合并
❓什么是蓝绿部署
蓝绿部署是一种将生产环境直接从当前版本(蓝色)切换到新版本(绿色)的策略。这要求同时运行两个完全相同的生产环境,但只有一个对外提供服务。
聚个贴近实际的栗子🌰,来讲述蓝绿部署
一个蛋糕店,有两个员工分别是"蓝"员工A,和"绿"员工B
他们共同推销店里的同一种老蛋糕 ,也就是线上正在运行的老项目
这个时候店长说有新品上市了,就把A员工叫回店里去拿新蛋糕 内测一下,也就是让蓝线去发布新需求v2.1.1 ,这条蓝线也只有店内自己评测,不会影响员工B老蛋糕销售,也就是不会影响线上正式环境
当员工A那里的新蛋糕评测完成后,就将B员工叫回店里,将A员工推出店外售卖,这样顾客就可以买到新蛋糕,也就是可以访问新的需求功能
当A员工新蛋糕卖的不错,也就是系统稳定后。再进行蓝绿部署平衡 ,将B员工也拿着新蛋糕和A员工一起售卖,进行合理负载
总结
概要
本文详细介绍了制定Git分支管理规范的必要性以及一个典型企业内部的Git分支管理流程,旨在通过规范化的Git操作促进团队高效协作、确保代码质量和提升开发流程的灵活性。
文章核心
-
为何制定规范:规范有助于加速团队协作,确保代码质量,维护主分支稳定,支持敏捷开发模式,便于问题追踪,加速新人融入,及促进代码复用。
-
我司Git分支结构:主分支:包括master(存放正式版本)、develop(日常开发主分支)、doc(文档与配置相关)。辅助分支:分为feature(特性开发)和hotfix(紧急修复),属于临时性分支,完成后会合并并删除。
实际操作流程
-
开发前:从develop分支创建带有特定命名规则的feature分支,如feature-功能名-版本号-日期,以保持团队同步并方便自动化部署。
-
开发中:团队成员基于功能分支各自拉取临时开发分支,实现灵活开发同时保持功能分支的稳定。
-
提测阶段:完成开发的成员将个人分支合并回功能分支,由测试团队基于此分支进行打包测试。
-
预生产准备:功能分支验证无误后,创建去除快照标识的预生产分支,用于模拟生产环境的最后测试。
-
部署上线:采用蓝绿部署策略,确保新版本无缝切换至生产环境,同时逐步完成各分支的合并,保证版本的连续性和环境的稳定性。