发布分支工作流教程

这个工作流适合什么场景

开始发布周期

main

2.02.1

develop

D1D2D3

功能冻结 + Bug 修复合并到 main + develop紧急修复双向合并

release / hotfix

release/2.2.0

R1R2

hotfix/login-timeout

H1

发布分支通常出现在这些场景：

• 版本已经接近上线，需要冻结功能
• 只允许接收发布相关修复
• 测试、文档、打包、验收需要一个稳定分支承载

它的核心目标不是继续堆新功能，而是把“准备发布”这件事和“主线继续开发”分开。

推荐顺序

1. 从稳定主线切出 release 分支

git switch main
git pull --ff-only
git switch -c release/2.4.0

切分支之前，先确保主线已经处于你认可的稳定状态。不要把“主线还没整理好”的问题带进发布分支。

2. 功能冻结，只接受发布相关修复

发布分支里通常只应该出现：

• bug fix
• 文案修正
• 配置调整
• 发布脚本修正

不应该在 release 分支上继续塞新的业务需求。

3. 发布完成后，把修复回流主线

git switch main
git merge release/2.4.0

如果某些修复还需要进入其他维护线，再根据情况继续 merge 或 cherry-pick。

一条更完整的发布节奏

git switch main
git pull --ff-only
git switch -c release/2.4.0
# 只接收发布相关修复
git add .
git commit -m "fix: adjust release config"
git switch main
git merge release/2.4.0

这里最关键的不是命令形式，而是“发布分支只做发布准备，不继续扩张范围”。

为什么发布分支要严格控范围

因为发布期最怕的不是功能少，而是变化面失控：

• 变更越多，验证越慢
• 风险越大，排障越难
• 发布回滚成本越高

一条健康的 release 分支，应该让所有人都知道：这上面现在只允许出现什么，不允许出现什么。

关键检查点

每次准备发布前，建议至少确认：

1. release 分支是从明确的稳定点切出来的
2. 最近进入 release 的提交都和发布直接相关
3. 主线和 release 之间的差异是可解释的

命令上可以配合：

git log --oneline --decorate -10
git diff --stat main...release/2.4.0

常见误区

误区 1：发布分支一开出来就继续接功能

这会让“发布准备”失去边界。

误区 2：只在 release 分支修，不回流主线

这样下一次版本准备时，同样的问题还会再出现一次。

误区 3：发布分支存在太久

发布分支应该服务于一次发布窗口，而不是无限期成为另一条主线。

特殊情况

• 如果团队采用 trunk-based 流程，可能会尽量缩短 release 分支生命周期
• 如果同时维护多个版本，发布分支和维护分支的回流方向要提前明确
• 如果线上修复直接落在 hotfix 分支，也要确保这些修复最终进入 release 和 main

相关命令

• git switch
• git branch
• git merge
• git diff
• git log
• git cherry-pick

接下来建议继续学什么

这一页之后，最适合继续看：

1. hotfix and urgent fixes
2. backport with cherry-pick
3. long-lived branch maintenance