环境分支模式
环境分支模式用一条分支对应一个部署环境，例如预发与生产各占一条，代码沿着固定方向逐级推进。结构直观，部署状态与分支一一对应，审计时容易说明线上跑的是哪条分支。代价是合并链路变长，修复可能需要在多条线上重复落地。
基本信息
| 结构 | 主干到预发再到生产，逐级推进 |
|---|---|
| 优点 | 部署状态与分支一一对应，便于审计 |
| 代价 | 合并链路长、修复需要在多处落地 |
| 替代方案 | 用同一次构建产物逐环境晋级 |
典型使用场景
- 有明确的预发与生产环境需要分别控制
- 发布需要人工确认节点，逐级推进更直观
- 审计或合规要求说明线上版本对应哪条分支
- 团队规模不大、发布频率不高时结构容易理解
- 从手工发布过渡到规范流程的中间形态
逐级推进
逐级推进
git switch main && git pull --ff-only # 主干先同步到最新
git switch pre-production && git merge --ff-only main # 推进到预发
git switch production && git merge --ff-only pre-production # 再推进到生产
git log --oneline -3 # 确认推进后的提交部署依据对照
| 做法 | 部署依据 | 代价 |
|---|---|---|
| 环境分支 | 分支名 | 合并链路长，修复要多处落地 |
| 制品晋级 | 同一个构建产物 | 需要制品库与流水线支持 |
| 标签发布 | 标签指向的提交 | 环境与版本的对应关系需自行维护 |
替代方案是用制品晋级：同一次构建产物依次经过各环境，避免在多条分支上重复合并，也减少预发与生产代码不完全一致的风险。
合并方向必须单一，只允许向上推进。出现回合并会让历史难以推理，环境之间的差异也说不清楚。
推进到下一个环境之前，先确认本环境已经验证通过；把「谁有权推进哪条分支」写进保护规则，能避免有人跳过预发直接改动生产分支。
环境分支的维护要点
- 每条环境分支都配上保护规则，限制直接推送
- 预发发现的问题先回到主干修复，再逐级推进
- 定期核对各环境分支的差异，确认只有预期的提交
- 发布记录里写明推进的提交范围，便于回溯