发布分支是什么
发布分支从主线切出后进入冻结状态：只接受针对本次发布的缺陷修复，不再引入新功能，从而把发布风险隔离出来。缺陷修复的流向遵循上游优先——先合回主线，再回挑到发布分支，这样下个版本不会重复踩同一个坑。它适合需要先冻结范围再统一测试、打包与上线的产品，主线上其他工作可以继续推进，不必为了等一次发布而全队停顿。
基本信息
| 用途 | 冻结发布范围、隔离发布风险 |
|---|---|
| 命名 | release/x.y，可配套发布标签 |
| 修复流向 | 先主线、后回挑发布分支 |
| 标签 | git tag -a v2.4.0 标记发布点 |
| 平台 | 任意 Git 客户端与托管平台 |
典型使用场景
- 发布前需要一段只收修复的稳定期
- 同时维护历史版本，需要独立修复通道
- 上线准备（版本号、打包、回归）需要一个固定基线
- 紧急修补已发布版本并同步回主干
- 为多版本长期支持划定各自的支持窗口
- 把发布范围与主线开发解耦，团队不必互相等待
常用示例
常用示例
git switch -c release/2.4.0 main # 从主线切出发布分支
git tag -a v2.4.0 -m 'release 2.4.0' # 打标注标签
git push origin release/2.4.0 v2.4.0 # 推送分支与标签
# 后续修复：先入 main，再挑回发布分支
git switch main && git cherry-pick <修复提交>
git switch release/2.4.x && git cherry-pick <修复提交>发布分支上的允许项
| 类型 | 是否允许 |
|---|---|
| 缺陷修复 | 允许，且需先合主线 |
| 文档与版本号调整 | 允许 |
| 新功能 | 不允许，走下个版本 |
| 大规模重构 | 不允许，避免引入不可控风险 |
发布分支存在期间主线继续前进，避免为了等一次发布而冻结整个团队；这也是它相对集成分支模型的主要优势。
修复只进发布分支会漏到下个版本，坚持上游优先；多条并行发布线要明确各自的结束时间与支持范围。