release分支必须从develop分支创建，仅当develop已集成本次全部功能并确认可发布；其上只允许修复阻断性bug、更新版本号及changelog；发布完成须先合并至main再合并至develop，随后立即删除。
Release 分支不是“测试分支”或“临时合并区”，它是一条有明确生命周期、严格准入规则、承担发布决策权的正式通道。用错就等于把预发环境当开发沙盒，上线风险直接翻倍。
Release 分支该从哪个分支创建？
必须从 develop 分支创建，且仅在此时创建——即 develop 已集成本次发布计划全部功能、通过冒烟测试、团队确认可进入发布流程。
- 禁止从
main或master创建：那属于 hotfix 场景，不是 release - 禁止从任意
feature/*或bugfix/*分支直接拉：会漏掉其他已合入develop的变更，破坏版本一致性 - 创建前务必执行
git pull origin develop，确保本地develop是最新状态，否则release-1.2.0的起点就不准
Release 分支上只允许做哪几件事？
它的权限是“只读 + 有限写入”，所有操作必须服务于“让这个版本能上线”，而不是“让代码更好看”。
- 修复阻断性 Bug：仅限测试发现的、不修改业务逻辑、不引入新依赖的紧急修复（例如空指针、配置路径错误）
- 更新版本号文件：如
package.json中的"version"字段，从1.2.0-SNAPSHOT改为1.2.0 - 生成或修订
CHANGELOG.md：基于本次develop → release的合并提交自动生成，人工核对即可 - 禁止新增功能、重构、调整依赖版本、修改 CI/CD 脚本逻辑——这些都该退回
develop处理
Release 分支合并回哪里？顺序为什么不能错？
发布完成时，必须**同时合并到 main 和 develop**，且顺序是：main 先，develop 后。
- 先合入
main：保证生产分支拿到最终可部署版本，后续打tag才有意义 - 再合入
develop：把版本号更新、Changelog 等元数据同步回去，避免下次 release 又从旧快照起步 - 如果只合
main不合develop：下个版本的develop里仍含-SNAPSHOT，版本号混乱；如果反过来先合develop再合main：可能把未验证的中间态带进生产 - 合并后立即删除本地和远程的
release-*分支，防止误操作复用
为什么 Release 分支不能长期存在？
它不是“稳定分支”，而是“临界分支”——存在本身就意味着正在做发布决策。拖得越久，越容易出现三类问题：
- 多人在同一个
release-1.2.0上提交修复，冲突概率飙升，且难以追溯谁改了什么 -
develop持续演进，导致release与develop差异越来越大，最后合入时 merge 冲突不可控 - 测试团队误以为“还在修”，开发团队误以为“已冻结”，实际两边都在动，版本基线彻底失焦
从创建到删除，理想周期应控制在 3–7 天内。超过两周还没发布的 release-*，大概率说明流程卡点没理清，该回溯的是协作机制，不是延长分支寿命。
