GitLab Flow 是面向 CI/CD 驱动交付的轻量分支模型，不设长期 develop 分支，主张功能分支直合 main 并由 CI 自动验证与部署；staging 和 production 为环境映射分支，需通过受控机制同步，严禁直接推送。
GitLab Flow 不是“比 Git Flow 更先进”的替代品，而是针对 CI/CD 驱动型交付场景设计的轻量、可扩展分支模型——它不强制 require develop 分支，也不要求 release/* 长期存在，关键在于“环境分支”与“CI 触发点”的绑定是否清晰。用错的前提，往往是把 GitLab Flow 当成 Git Flow 的简化版来用。
为什么不能直接把 Git Flow 的 develop 分支照搬进 GitLab Flow
Git Flow 中的 develop 是一个长期集成分支，所有 feature/* 合并到它，再由它派生 release/*；而 GitLab Flow 默认不设 develop，主张功能分支直接合入 main（或 master），靠 CI 流水线自动验证是否可部署。强行保留 develop 会导致：
- CI 流水线触发点模糊：你不确定该在
develop还是main上跑 full test suite - 环境分支失去意义：如果
staging分支只是develop的镜像，那它和develop就是冗余的两层抽象 - 发布节奏被拖慢：必须等
develop稳定才能切release/*，违背 GitLab Flow “每个main提交都应可发布”的前提
正确做法是：删掉 develop，让 main 承担“可发布主线”角色，所有功能分支基于 main 创建，通过 PR 合并，并由 CI 自动部署到 staging。
staging 和 production 分支怎么建、怎么同步
staging 和 production 是 GitLab Flow 的核心环境分支，它们不是“开发中”和“已上线”的状态标记，而是部署目标的明确映射：
-
staging分支应由 CI 在每次成功合并 PR 到main后自动 fast-forward 更新（即git merge --ff-only main） -
production分支不应直接接收 PR，而应通过 tag 或 protected branch + manual approval trigger 部署 - 禁止开发者向
production直接 push，也不建议用git merge手动同步 —— 容易绕过审批、丢失部署上下文 - 若需热修复，从
production派生hotfix/*，修复后先合入main（保证主干最新），再 cherry-pick 到production并打 tag
示例命令流：
git checkout -b hotfix/db-connection-timeout production<br>git commit -m "fix: increase timeout to 30s"<br>git push origin hotfix/db-connection-timeout<br># PR into main first<br>git checkout main<br>git cherry-pick <commit-hash><br>git push origin main<br># then manually apply to production with tag<br>git checkout production<br>git cherry-pick <commit-hash><br>git tag v2.1.3<br>git push origin production v2.1.3
feature 分支命名和生命周期控制的实际约束
GitLab Flow 对 feature/* 的管理更强调“短生命周期”和“单责任”，不是语法规范问题，而是 CI/CD 效率问题：
- 命名必须含业务语义，禁用
feature/abc123类编号，推荐feature/user-invite-link-expiry - 存活时间建议 ≤2 天：超时未合并的分支，CI 流水线会因 base 分支（
main）变更而频繁失败，重基成本陡增 - 禁止跨环境提交：不要在
feature/*中硬编码staging或production的配置，应通过 CI 变量注入 - 每个
feature/*必须关联一个 issue 或需求 ID（如feat(user-invite): add expiry param），便于追溯发布范围
GitLab 内置的 auto-devops 或自定义流水线，会默认监听 feature/* 分支的 push 事件，启动独立测试环境；若分支闲置太久，该环境资源可能被回收，导致后续调试困难。
权限设置最容易被忽略的三个细节
GitLab Flow 的协作效率高度依赖分支保护规则，但多数团队只设了“禁止 push to main”，漏掉了关键项：
-
staging分支必须设为 protected，并开启 “Allow including specific users or groups in the list of approvers”，否则无人能批准部署到预发环境的 MR -
production分支需启用 “Require at least X approvals” 且勾选 “Include administrators” —— 即使你是 Owner，也不能跳过审批 - 所有
feature/*分支应允许开发者自由创建和推送，但禁止直接合并（Merge button disabled），必须走 MR 流程 —— 否则会破坏 CI 触发链路
还有一个隐性陷阱：main 分支的 “Allowed to merge” 权限组，必须和 CI pipeline 的 runner token 权限一致。常见错误是给开发组开了 merge 权限，但 runner 使用的是 deploy 组 token，导致 pipeline 因权限不足无法部署到 staging。
