前言

当下git对开发的重要性不必多言，如何让团队更好地使用git，值得花点精力研究。

提交信息模板

类型(范围):主题(最多50个字)
解释为什么要做这些改动
提供相关文章和其它资源的链接和关键字 

类型说明：

• feat (新特性)
• fix (bug修复)
• remove(删除特性)
• docs (文档改动)
• style(格式化， 缺失分号等)
• refactor (重构代码)
• test (添加缺失的测试，重构测试)
• chore (构建任务等)

范围说明：一般指页面或模块

提交信息示例：

feat(顶栏):增加用户头像
refactor(底栏):函数set重命名为setTitle

优秀的提交信息，能让我们查看历史提交时，能更容易和更快速的理解做了什么。如果每次提交都写fix bug，相当于没写。

提交原子性

代码提交的原子性，是指一个提交包含一个不可分割的特性、修复或者优化，同时这个提交要尽可能小。

1. 以单一职责原则提交改动

建议：独立的功能点、模块、组件或修复bug等。

2. 每次提交保证可运行

没有人希望拉取了你的代码后运行报错。

3. 多人合作时，尽早提交，尽早拉取

这么做是为了降低代码冲突的问题，解决冲突一般来讲，既耗费人力也耗费时间。

分支

关于分支，每个团队的情况都不同，并不能一概而论。所以我们得根据自身的情况，来选择合适的git工作流，既不能太复杂难用，也不能简单到混乱，合适舒服就是最好的。

禁忌

• 禁止推送主分支
• 禁止使用git push -f

尽量在仓库里禁止以上行为。

为什么要制定Git分支管理规范

• 加速团队协作，让成员明确各分支用途。
• 确保代码质量，通过审查保证稳定性和高质量。
• 维护主分支稳定，避免未完成代码干扰生产环境。
• 支持敏捷开发，适应快速迭代和持续集成。
• 便于问题解决，快速定位错误来源。
• 新人快速上手，标准化流程易于理解。
• 促进代码复用，鼓励模块化开发。

Git分支都有哪些

主分支

主干分支具有分支保护权限，只有运维有权限进行合并分支

分支模型	用途
master	主干分支，正式版本代码归档
develop	开发分支，团队成员日常开发的主分支
doc	文档分支，SQL脚本、配置等

辅助分支

属于临时分支，当功能合并主干后，会删除清理掉

分支模型	用途
feature	从develop拉取开发的功能分支
hotfix	bug修复分支

Git分支在实际开发中使用流程

举例

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