GitLab Flow 是什么
GitLab Flow 在 GitHub Flow 的基础上补了「部署到哪」这一层：可以用环境分支（如 main → pre-production → production）逐级向上合并，也可以用发布分支（从 main 切 release/x.y）承载线上版本。它的核心原则是上游优先——修复先合主线，再决定是否回挑到发布线，从而避免修复只落在发布分支、下个版本又复发。适用于需要显式区分环境或版本的团队。
基本信息
| 变体一 | 环境分支：main → pre-production → production 逐级合并 |
|---|---|
| 变体二 | 发布分支：从 main 切 release/x.y，修复先合 main |
| 核心原则 | 上游优先，减少修复遗漏 |
| 适用 | 需要区分部署环境或维护版本线的团队 |
| 平台 | GitLab 官方文档提出，其他平台同样适用 |
典型使用场景
- 测试、预发、生产多套环境需要明确对应关系
- 需要维护多个已发布版本，修复要能回挑
- 团队已有 GitHub Flow，但缺少发布落点
- 上线节奏固定，希望每条环境线有清晰的推进方向
- 修复线上问题后要求不遗漏后续版本
- 作为从轻量流程走向规范化流程的中间形态
环境分支示意
环境分支示意
# main → pre-production → production
# 合并方向单一，逐级向上推进
# 缺陷修复：先合 main，再决定是否回挑发布分支
# 环境分支只作为部署落点，不作为新功能的开发起点两种变体对比
| 变体 | 适合 |
|---|---|
| 环境分支 | 部署环境固定、发布节奏单一 |
| 发布分支 | 需要长期维护多个已发布版本 |
上游优先（upstream first）能避免修复只落在发布分支、下个版本又复发的问题，是这套流程最值得坚持的一条。
环境分支与部署状态的对应关系要保持单一事实来源：分支表示代码状态，部署记录交给流水线，避免两处各说各话。