Git

背景与问题界定 一个 60 人规模的工程团队在使用 Git 时暴露出一系列紊乱现象：开发人员直接在 main 分支上提交修改导致生产事故回滚困难；功能分支长期存活（超过两周不合并）造成大量合并冲突；Hotfix 流程混乱，紧急修复绕过 Code Review 直接合入；GitLab CI 流水线中 30% 的构建失败是因为提交信息不规范导致无法自动生成 ChangeLog。Git 作为分布式版本控制的"元工具"，其工作流设计直接影响团队协作效率、发布质量和事故响应速度。缺乏统一的分支策略和自动化保护机制，Git 仓库很快就会变成"混乱的共享便签本"。 目标拆解与工程约束 分支模型标准化：必须定义清晰的分支生命周期——哪些分支存在、如何命名、从哪创建、合入哪去、何时删除——让任何一个开发者在 5 分钟内能理解当前仓库的开发和发布状态。 自动化保护门禁：关键分支（main、release）必须受到保护，不能直接 push，MR/PR 必须通过自动化流水线检查（构建通过 + 安全扫描 + 单元测试 + 至少一人 Approve）才能合入。 提交规范自动化：所有提交信息必须遵循 Conventional Commits 规范，自动解析 feat、fix、chore 等前缀生成语义化版本和 ChangeLog，阻断不合规的提交。 紧急响应流程：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 实现： ...