GitLab Topic
GitLab Flow 与 Merge Request 教程
理解 GitLab Flow、环境感知的分支协作，以及 Merge Request 为什么会成为 GitLab 交付模型的中心。
- 已经会基础 Git、准备系统学习 GitLab 协作的人
- 要在团队里使用 Merge Request、Issue Board 和 CI/CD 的开发者
- 知道 branch、commit、push、remote 的基本作用
- 愿意把平台功能和 Git 操作一起理解
- 只记 GitLab 页面操作却忽略底层 Git 边界
- 把平台策略误当成可以替代本地历史判断
GitLab Flow 的位置到底在哪里
GitLab Flow 不是对 GitHub Flow 的简单换皮，也不是 Gitflow 的直接复制。
它真正强调的是：分支协作要和交付现实绑定在一起。
所以它关注的不只是：
- 代码怎么合并
还包括：
- 代码要往哪个环境走
- 哪些条件构成 merge readiness
- 分支是在表达协作状态，还是交付状态
如果只盯着分支名或 MR 页面，很容易误解 GitLab Flow。它真正有价值的地方，是把 branch、pipeline、approval 和 delivery gate 组织成一个完整模型。
为什么 Merge Request 是这套模型的核心
在 GitLab 中，Merge Request 往往同时承载：
- 变更说明
- code review
- pipeline 结果
- approvals
- 是否满足合并条件
这意味着 MR 在 GitLab 里不只是“代码比对页”，更像一个真正的协作和准入关口。
一条常见的 GitLab Flow 节奏
- 从默认分支或指定整合分支切工作分支
- 在工作分支提交改动
- 打开 Merge Request
- 让 pipeline、review 和 approvals 在 MR 里汇合
- 条件满足后再合并
如果团队还有环境分支、稳定分支或发布分支，这条线会继续往部署和回流延伸，但 MR 仍然是中枢。
它适合什么团队
GitLab Flow 特别适合这些场景：
- CI/CD 已经深度参与协作决策
- 环境推进和部署状态很重要
- 团队希望在一个地方同时看到 review、自动化和准入条件
如果团队只想要极轻量分支模式，又几乎不用 CI / approval / environment，这套模型的优势就会弱很多。
常见误区
- 把 GitLab Flow 理解成“带 MR 的 feature branch”
- 只看 MR 页面，不看围绕它的 pipeline 与审批规则
- 分支活得太久，让 MR 越来越难评审
- 先套复杂分支结构，再去想团队实际上有没有这样的交付需求
更稳的落地顺序
很多团队按下面顺序推进会更稳：
- 先明确默认协作分支
- 再明确什么条件才算 MR 可合并
- 把这些条件落进 pipeline 和 approvals
- 只有交付模型确实需要时，才继续引入环境分支或发布分支
这样能避免流程设计先于真实需求，导致团队只是在维护一套“看起来很完整”的分支制度。
图例理解
工作分支Pipeline 状态Review / Approval
可合并变更被阻止的变更面向交付的分支状态
如果团队把 MR 仅仅当成 diff 页面，就会错过 GitLab Flow 真正的组织价值。
很多团队真正需要的不是更多 branch，而是更清楚的 MR 准入规则。分支复杂度应该服务于交付，而不是反过来。
无论流程图画得多漂亮，只要分支活太久，MR 的 review、测试和信任成本都会上升。
跟着做一遍
目标是把 MR 看成决策界面，而不是点 Merge 的地方。
从默认协作分支切一个小分支。 做一处明确改动并打开 MR。动手试
- 观察这个 MR 里出现了哪些 pipeline 检查。
- 观察哪些 approval 或分支规则影响它能否合并。
- 判断这个分支只是协作分支，还是还代表环境或发布状态。
- 把“什么条件下它才算 ready”写下来。
- 你会意识到 GitLab Flow 不只是 branch 命名，而是 policy 和 automation 一起工作的模型。
- 会更容易看出哪些关口是技术性的，哪些是组织性的。
- 也能更判断团队当前的分支模型是不是过度设计。
- 如果流程显得很复杂，先问交付模型是不是真的需要这些分支。
- 如果 MR 成了唯一上下文入口，通常说明上游计划层还不够健康。
- 如果 merge readiness 说不清，先定义规则再加流程。
上下篇
上一篇当前方向没有更多内容
下一篇GitLab Fork 与贡献流程命令专题