github flow 仅维护 main 分支，所有变更通过 pr 合入并立即部署，适用于高频发布场景；gitlab flow 增加 staging/production 环境分支，要求代码单向流动、分层验证，适用于多环境隔离与合规要求高的项目。
GitHub Flow 和 GitLab Flow 不是 Git 内置功能，而是团队协作约定的分支管理策略——选错模型，PR 合并会卡在环境流转、发布节奏失控、甚至线上回滚找不到对应 commit。
GitHub Flow：只有一个主分支，所有变更都走 PR
它把 main（或 master）当作唯一长期分支，始终可部署。新功能、Bug 修复、文档更新，全从 main 拉出短期分支（如 feature/login-ui），改完提 Pull Request，审核通过后直接合入 main，立刻触发 CI/CD 部署。
- 适用场景：Web 应用、SaaS 服务、CI/CD 流水线成熟、发布频率高（每天多次）
- 关键约束：
main必须永远 green（CI 通过）、永远可部署；分支生命周期短（建议 ≤ 3 天） - 容易踩的坑：
feature分支长期不合并，导致main被跳过同步，最终合入时冲突爆炸；没配自动测试，靠人工点“Merge”就上线 - 不需要
develop、release这类中间分支——加了反而破坏模型本意
GitLab Flow：按环境分层，代码单向向下流动
它在 GitHub Flow 基础上引入环境分支，要求代码必须从上游流向下游：main → staging → production。新功能仍从 main 拉分支，但合入后不是直奔生产，而是先到 staging 测试，验证通过再 cherry-pick 或合并到 production。
- 适用场景：需要灰度发布、多环境隔离（如预发/压测/生产）、合规审计要求高（如金融、政企项目）
- 参数差异：
staging分支通常绑定预发环境，production分支打 tag 并受保护（仅允许 merge request + maintainer approve） - 常见错误现象：
git push origin main直接推到production；或把staging当开发集成分支，导致测试环境不稳定 - 性能影响：多一层分支流转，发布延迟增加（但换来环境可控性）；CI 流水线需为每个环境配置独立触发规则
Git Flow 不等于 GitHub Flow，别混用命名
很多团队误把 feature/* 分支命名方式当成 GitHub Flow，其实 Git Flow 的 feature/* 是从 develop 拉的，而 GitHub Flow 的 feature/* 只能从 main 拉。两者分支起点不同，合并目标也不同——混用会导致 git log 看起来像两套系统在打架。
-
git checkout develop && git checkout -b feature/x是 Git Flow 典型操作，不属于 GitHub Flow - GitHub Flow 下，
git checkout main && git checkout -b hotfix/db-timeout才是合法路径 - GitLab Flow 允许
feature/*合入main，但禁止直接合入production；Git Flow 则要求hotfix/*必须从main拉、合回main和develop
真正难的不是记住分支名，而是让整个团队对「哪个分支代表哪个环境」「谁有权 push 哪个分支」「合并前必须满足什么条件」达成一致——这些规则一旦写进 .gitlab-ci.yml 或 GitHub Actions 的 on: pull_request 触发器里，就很难绕开。
