2. GitLab分支模型选型

分支模型不是“哪种更先进”的问题，而是“哪种更匹配当前发布节奏、团队规模与合规约束”的问题。在大型团队中，选错分支模型的代价通常不是多几次合并，而是发布窗口失控、审计链断裂、热修复无法追溯。本节把四种主流模型放在同一组维度下对比，并给出一套可落地的选型判断方法。

四种模型的核心结构差异

Git Flow 用长期分支 develop 承载集成，用 main 承载已发布版本，配合 feature/*、release/*、hotfix/* 三类短分支。它的优势是发布节奏与开发节奏解耦：功能可以持续并入 develop，而 release/* 冻结后只接受缺陷修复，适合有明确版本号、需要同时维护多个历史版本的场景。代价是分支数量多、合并路径长，develop 与 main 长期分叉，一旦团队不严格执行“只从 release 合入 main”，就会出现版本内容漂移。

GitHub Flow 只保留 main 一条长期分支，所有改动走短分支加合并请求，合并即具备发布条件。它把复杂度压到最低，适合持续部署、单版本在线的产品。但在大型团队中，它缺少“发布冻结”这一层，当合规要求“上线前必须经过独立评审与回归”时，只能靠外部流程补，容易与代码状态脱节。

GitLab Flow 是介于两者之间的折中：保留 main 作为集成分支，再按环境或版本拉出 pre-production、production 或 1-2-stable 这类分支，改动通过合并请求从上游流向下游，且只允许单向流动。它天然贴合 GitLab 的 MR、CI/CD、环境与审批能力，适合“有多个部署环境、需要环境级审批”的大型团队。

主干开发（Trunk-Based Development） 要求所有人频繁向 main 提交，短分支存活时间通常不超过一天，未完成功能用特性开关隐藏。它换来的是极高的集成频率和极低的合并冲突，但对自动化测试覆盖率和特性开关治理要求最高，否则未完成代码会直接进入可发布状态。

选型必须回答的三个问题

第一，发布节奏。如果每个季度只发一次版本、且要同时维护 1.0 与 1.1 两条线，Git Flow 的 release/* 与 hotfix/* 能直接承载这种节奏；如果每天甚至每次合并都上线，主干开发或 GitHub Flow 更自然；如果按环境逐级推进（测试→预发→生产），GitLab Flow 的环境分支与单向流动最省心。

第二，团队规模。分支模型本质是协作协议。50 人以上、跨多个子团队时，长期分支越多，合并冲突与“谁该合谁”的沟通成本越高。此时应优先减少长期分支数量，把复杂度转移到自动化门禁上。主干开发在 200 人以上团队中反而更常见，前提是 CI 能在 10 分钟内给出可信结果。

第三，合规要求。金融、医疗、车载等场景常要求“每个上线版本可追溯到具体评审记录与测试报告”。Git Flow 与 GitLab Flow 天然保留发布分支与合并请求记录，审计友好；GitHub Flow 与主干开发则需要额外用标签、发布记录和流水线归档来补齐证据链。

大型团队的推荐组合

实践中很少有团队纯用某一种模型。更常见的做法是“主干 + 发布分支”的混合：日常开发走短分支合并到 main，接近发布时从 main 切出 release/x.y 冻结，只接受经审批的缺陷修复，修复后再回合 main。这实际上是用 GitLab Flow 的环境/版本分支思路，吸收了 Git Flow 的发布冻结能力，同时避免长期维护 develop。

下面给出一份可直接套用的选型决策表，按“发布节奏—团队规模—合规强度”三列定位推荐模型：

落地时的关键约束

无论选哪种模型，大型团队都要守住三条底线。其一，保护分支：main、production、release/* 必须禁止直接推送，只允许通过合并请求进入，并配置至少一名非作者的审批人。其二，单向流动：下游分支（如 production）的修复必须回合上游 main，否则下次发布会把已修复的缺陷重新带回来。其三，命名与生命周期：短分支建议统一为 feature/工单号-简述，合并后自动删除；长期分支数量控制在 3 条以内，超过就说明模型需要简化。

可以用一段 GitLab CI 配置来强制“合并请求必须通过测试且至少一人审批”，这是把分支模型从约定变成约束的最小手段：

stages:
  - test
  - review

unit_test:
  stage: test
  script:
    - npm ci
    - npm run test:unit
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'

merge_guard:
  stage: review
  script:
    - echo "检查审批人数与流水线状态"
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
      when: manual
  allow_failure: false

判断模型是否选对，可以观察三个信号：合并请求平均存活时间是否持续超过 3 天；main 与发布分支的差异提交是否长期无人回合；发布前是否需要人工逐条比对分支内容。若出现其中任意一条，说明当前模型与团队节奏已经不匹配，应回到“发布节奏—团队规模—合规要求”三个维度重新定位。