03-企业分支规范讲解：Master/Develop/Feature/Bugfix/Release分支模型

03-企业分支规范讲解：Master/Develop/Feature/Bugfix/Release分支模型

一、为什么要有分支规范？

上一篇我们搞懂了Git的底层原理——commit是一串哈希指针。那问题来了：团队10个人，每个人都往master上提交，master就成了一条"大杂烩"线，谁知道哪个commit是测试过的？哪个是线上版本？哪个是半成品？

分支规范的本质就是用分支隔离关注点：开发归开发，测试归测试，发版归发版，紧急修复归紧急修复。每条分支有明确的职责、明确的来源、明确的去向。

目前业界最主流的分支模型有两种：

• Git Flow：经典模型，分支多、流程重，适合发版周期长、多端协作的项目
• GitHub Flow / Trunk-Based：轻量模型，只有master + feature，适合持续部署的Web项目

我们的无人售货柜项目涉及后端微服务、安卓固件、小程序三端，发版周期不同步、需要严格的版本管控，Git Flow是更合适的选择。

二、五大分支的职责与生命周期

2.1 Master分支——生产环境的唯一来源

命名：master (或 main) 来源：从 Release 分支合并 去向：无（它是终点） 保护级别：最高，禁止直接push

Master分支上每个commit都对应一个生产环境版本。无人售货柜线上跑的后端v1.2.0、安卓固件v1.2.0，一定能在master上找到对应的Tag。

关键规则：

• 永远不要在master上直接开发
• master的每次合并必须来自Release分支经过完整测试的代码
• 每次合并到master后必须打Tag，格式如v1.2.0-backend

2.2 Develop分支——集成测试的主线

命名：develop 来源：从 master 拉出，长期存在 去向：合并到 Release 分支 保护级别：高，只接受合并，不直接push

Develop是所有Feature分支的"汇合点"。开发者在Feature分支完成开发后，合并到Develop进行集成测试。Develop上的代码应该是最新可用的开发版本，但不保证稳定——因为多个Feature合并后可能有冲突。

关键规则：

• Feature分支完成后合并到Develop
• Develop定期与master同步（把master的Bugfix合并回来）
• 不要直接在Develop上写代码，通过Feature分支合并

2.3 Feature分支——功能开发的工作区

命名：feature/开门接口字段统一改造 来源：从 develop 拉出 去向：合并回 develop 生命周期：功能完成后删除

每个功能点一个Feature分支，命名要见名知意。比如后端要改造开门接口返回字段，分支名叫feature/door-api-field-refactor，而不是feature/zhangsan——三个月后没人记得张三做了什么。

关键规则：

• 一个Feature尽量在一个迭代周期内完成
• Feature分支开发期间，定期从Develop拉取最新代码（git merge develop或git rebase develop），避免积累冲突
• 合并到Develop后，删除远程和本地的Feature分支

2.4 Bugfix分支——线上Bug紧急修复

命名：bugfix/货柜门状态不回传 来源：从 master 拉出（注意是master，不是develop） 去向：合并回 master 和 develop 生命周期：修复验证后删除

线上出了Bug，从master拉Bugfix分支，修复后合并回master发版，同时合并回Develop保证后续开发不会踩同一个坑。

为什么从master拉而不是从develop？因为develop上可能有未测试通过的新功能代码，基于develop修复Bug会带入不可控的变更。master是稳定的线上版本，从它拉分支修复最安全。

关键规则：

• Bugfix分支只修Bug，不加功能
• 修复后必须同时合并到master和develop（双合并）
• 合并到master后打新版本Tag，如v1.2.1-backend

2.5 Release分支——发版前的冻结与预检

命名：release/v1.2.0 来源：从 develop 拉出 去向：合并到 master 和 develop 生命周期：发版后删除

当Develop上累积了足够的功能，准备发版时，从Develop拉出Release分支。Release分支进入"冻结期"——不再加新功能，只做Bug修复、版本号更新、配置调整。

Release分支的意义在于隔离发版准备和持续开发：测试团队在Release分支上做回归测试，开发团队可以继续在Develop上开发下个迭代的功能，互不干扰。

关键规则：

• Release分支只允许Bugfix提交，不允许新功能
• 测试通过后合并到master打Tag发布
• 同时合并回Develop（把Release期间的Bugfix同步回去）
• 合并方式用--no-ff保留合并记录

三、分支流转全景图

master ●─────────────────●───────────────●────────── (Tag v1.2.0) \ ↑ /↑ \ │ / │ develop ●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●● \ ↑ ↑ ↑ ↑ ↑ \ │ │ │ │ │ feature ●●●●●●● ●●●●●●●●● │ │ │ │ │ │ │ │ release ●●●●●●●● │ │ │ │ │ bugfix ●●●●●●●●●● │ (合并到master+develop)

四、无人售货柜项目分支实战示例

以一次完整迭代为例：

迭代目标：后端开门接口字段统一改造 + 安卓固件适配 + 小程序支付流程优化

第1天：从develop拉出三个Feature分支 feature/door-api-field-refactor (后端) feature/firmware-door-api-adapt (安卓固件) feature/miniapp-payment-optimize (小程序) 第1-7天：各端在各自Feature分支开发 后端完成接口改造，安卓固件适配新字段，小程序优化支付流程 第7天：三个Feature分支合并到develop develop上进行联调测试 第8天：从develop拉出release/v1.2.0 测试团队在release分支做回归测试 发现安卓固件有个Bug：door_status字段解析时类型转换错误 第8-9天：在release/v1.2.0上修复Bug 同时把这个Bugfix合并回develop 第10天：release/v1.2.0测试通过 合并到master，打Tag：v1.2.0-backend / v1.2.0-firmware / v1.2.0-miniapp 合并回develop 删除release/v1.2.0和三个feature分支 第11天：线上发现小程序支付回调偶发失败 从master拉出bugfix/payment-callback-fix 修复后合并到master打Tag v1.2.1-miniapp 合并回develop

五、合并策略：merge vs rebase vs squash

推荐策略：

• Feature → Develop：git merge --no-ff（保留分支痕迹，方便追溯哪个功能是谁做的）
• Release → Master：git merge --no-ff（明确标记发版点）
• Bugfix → Master：git merge --no-ff（标记修复点）
• Feature开发期间同步Develop：git rebase develop（保持线性历史，减少merge commit噪音）

六、分支保护规则配置

在GitLab/Gitea中配置分支保护：

配合CI流水线：只有CI通过的Merge Request才能合并到develop/master，从机制上杜绝"漏测"代码进入主干。

分支规范不是形式主义，它是团队协作的"交通规则"——每个人都按规则走，代码就不会撞车。下一篇我们把这个模型落地到无人售货柜三端项目中，讲清楚后端微服务、安卓固件、小程序各自的分支怎么管、怎么对齐。