背景与问题界定

一个 60 人规模的工程团队在使用 Git 时暴露出一系列紊乱现象：开发人员直接在 main 分支上提交修改导致生产事故回滚困难；功能分支长期存活（超过两周不合并）造成大量合并冲突；Hotfix 流程混乱，紧急修复绕过 Code Review 直接合入；GitLab CI 流水线中 30% 的构建失败是因为提交信息不规范导致无法自动生成 ChangeLog。Git 作为分布式版本控制的"元工具"，其工作流设计直接影响团队协作效率、发布质量和事故响应速度。缺乏统一的分支策略和自动化保护机制，Git 仓库很快就会变成"混乱的共享便签本"。

目标拆解与工程约束

  1. 分支模型标准化：必须定义清晰的分支生命周期——哪些分支存在、如何命名、从哪创建、合入哪去、何时删除——让任何一个开发者在 5 分钟内能理解当前仓库的开发和发布状态。
  2. 自动化保护门禁：关键分支（main、release）必须受到保护，不能直接 push，MR/PR 必须通过自动化流水线检查（构建通过 + 安全扫描 + 单元测试 + 至少一人 Approve）才能合入。
  3. 提交规范自动化：所有提交信息必须遵循 Conventional Commits 规范，自动解析 feat、fix、chore 等前缀生成语义化版本和 ChangeLog，阻断不合规的提交。
  4. 紧急响应流程：Hotfix 必须有加速通道——允许跳过部分检查但必须有事后补录机制，不能因为流程过重而延误线上事故处理，同时保证所有操作在 Git 历史中完全可追溯。

方案设计

我们基于 Trunk-based Development（主干开发）思想，结合 GitLab Flow 的发布分支策略设计了"三级分支模型"：

  • main：唯一长期分支，始终处于可发布状态。所有合并必须通过 MR + CI 全量流水线检查，禁止 Direct Push。Commit 历史必须是线性（Merge request with semi-linear history），便于 git bisect 定位回归。
  • feature/ 或 fix/**：短期分支（存活时间 <= 72 小时），从 main 创建，必须 rebase main 后通过 Squash Merge 合入。超过 3 天未合并的分支触发自动化提醒脚本。
  • release/v 或 hotfix/v**：从 main 的特定 commit 创建，用于生产版本发布和紧急修复。发布完成后合并回 main 和对应的 release 分支，删除过期（超过 2 个版本迭代）的 release 分支。

自动化保护通过 GitLab 的 Protected Branches 和 Merge Request Approvals 实现：

# .gitlab-ci.yml 中的提交规范检查
check-commit-format:
  stage: lint
  script:
    - apt-get update && apt-get install -y nodejs
    - npx commitlint --from $CI_MERGE_REQUEST_DIFF_BASE_SHA --to $CI_MERGE_REQUEST_SOURCE_BRANCH_SHA
  only:
    - merge_requests
  allow_failure: false

Commitlint 配置 @commitlint/config-conventional，结合 Husky Git Hooks 在客户端也做一次预检查形成双重保障。语义化版本自动生成通过 semantic-release 工具实现——解析 feat -> 次版本号递增，fix -> 补丁版本号递增，BREAKING CHANGE -> 主版本号递增，自动发布到 NPM 内部 Registry。

Hotfix 流程允许维护者通过 -ff hotfix 标签绕过 Code Review 门禁，但 CI 构建和冒烟测试仍必须通过，且合并后自动创建 JIRA 工单要求 24 小时内补录 Code Review。所有 Hotfix 操作通过 git revert 的历史记录和 --no-ff 保留合并节点来保证审计追溯。

实施路径与关键决策

  • 第一步：在 GitLab 中配置 Protected Branches，将 main 和 release/* 分支设置为不可 Direct Push，配置 Merge Request 流水线必须全部通过（包括 Lint、测试、安全扫描），设置至少 2 位 Maintainer Approve 才能合入。
  • 第二步：团队内推进 Conventional Commits 规范培训，同时在 CI 中集成 commitlint 和 commitizen 交互式提交工具，通过 git cz 引导规范提交信息的格式。
  • 第三步：配置 semantic-release 配合 GitLab CI 的 release 功能，在合并到 main 后自动生成 Release Notes 和 Tag，通过 Webhook 推送到企微群和飞书文档。
  • 第四步：搭建分支清理自动化——通过 GitLab API 的 merge_requests 端点编写定时任务，每日扫描超过 72 小时的活跃分支，发送 Slack 提醒，7 天后自动删除。

验证指标与可持续迭代

流程有效性通过以下指标衡量：主线分支上的 Direct Push 事件降为 0；MR 合入前的 CI 通过率从 60% 提升到 95%；分支平均存活时间从 8 天降至 1.5 天；版本发布从手动操作变为完全自动化，每次发布耗时从 30 分钟降至 30 秒。每两周做一次 Git 工作流健康度复盘，检查"不规范提交"数量和"绕过流程"的 Hotfix 占比。

工程落地思考

Git 工作流的核心不是"哪个分支模型最好"，而是"哪个模型能被团队一致执行"。我们尝试过 Git Flow 标准模型（5 类分支），结果 60 人团队没人能说清 release 和 develop 分支的准确用途，最终简化到 3 类分支才真正落地。Conventional Commits 最大的阻力来自开发者习惯——他们觉得 git commit -m "fix bug" 很方便。解决方案不是强制执行，而是用 commitizen 降低输入成本，让工具自动补全类型，并在 MR Title 中展示规范提交的格式收益（自动关联 JIRA issue、自动生成 Release Notes）。一个好的 Git 工作流，应该像自动驾驶——大部分时候你感觉不到它的存在，但每个关键节点它都在替你正确地做决策。