【规范】Git分支管理，看看我司是咋整的

前言

缘由

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-功能名-版本号-日期，以保持团队同步并方便自动化部署。
开发中：团队成员基于功能分支各自拉取临时开发分支，实现灵活开发同时保持功能分支的稳定。
提测阶段：完成开发的成员将个人分支合并回功能分支，由测试团队基于此分支进行打包测试。
预生产准备：功能分支验证无误后，创建去除快照标识的预生产分支，用于模拟生产环境的最后测试。
部署上线：采用蓝绿部署策略，确保新版本无缝切换至生产环境，同时逐步完成各分支的合并，保证版本的连续性和环境的稳定性。

猜你想问

如何与狗哥联系进行探讨

关注公众号【JavaDog程序狗】

公众号回复【入群】或者【加入】，便可成为【程序员学习交流摸鱼群】的一员，问题随便问，牛逼随便吹，目前群内已有超过280+个小伙伴啦！！！

2.踩踩狗哥博客

javadog.net

大家可以在里面留言，随意发挥，有问必答