5.2 分支策略与团队规范

5.2 分支策略与团队规范

本节摘要：工作流选型只有一句话，规范才是每天被执行的制度。本节给出一份可直接落地的团队法典范本——分支命名、合并门槛、强推边界、发布纪律——并说明每条规则背后对应的对象模型依据，让规范"知其所以然"。

从口头约定到团队法典

1. 能制定一套自洽的分支命名体系
2. 能配置平台层的分支保护与评审门槛
3. 能划定 force push 与历史改写的允许边界
4. 能把发布、热修、清理写成可执行流程

一、分支命名：让引用列表自己会说话

refs/heads 目录就是团队的共享工作台，命名体系的目标是任何人扫一眼 git branch -a 就知道每条分支是什么、属于谁、什么状态。推荐结构：类型/简述-编号，类型前缀与 5.1 的分支角色对齐。

feature/pdf-export-142     # 功能 关联任务142
fix/login-timeout-98       # 修复
hotfix/v1.2.1-crash        # 紧急修复 带目标版本号
chore/upgrade-deps         # 杂务
experiment/新方案试验        # 探索性 允许烂尾
​

三条配套纪律：编号挂靠（分支名带任务系统编号，评审者可溯源）；人名不进分支名（分支属于变更不属于个人，author 字段已记录归属）；一次性（合并即删，平台端开启"合并后自动删除分支"）。第 4 章的 fetch --prune 配合自动删除，远程引用列表常年清爽。

二、主干保护与合并门槛

制度写在纸上一半，锁在平台上一半。最低配置集：主干禁止直推（必须走合并请求）、至少一人批准、CI 通过方可合并、线性历史可选强制（拒绝合并提交或自动 squash）。以 GitLab 为例的保护分支设置项与 GitHub 的 branch protection 大同小异，核心都是把"引用更新权"从个人收归流程——第 4 章说过 push 只是"请求更新引用"，保护规则就是服务端对请求的裁决器。

合并方式三选一要在规范里写死，因为三者历史形态不同（第 2 章 2.3 的形态对比在此落地）：

• merge commit：保留完整拓扑与讨论上下文，历史图有分叉；
• squash merge：功能分支 N 个提交压成主干上 1 个，主干极度干净，但中间过程只在平台界面可见；
• rebase merge：逐提交复印到主干，保留细粒度但不留合并节点。

我的推荐：功能以"一个变更一个意图"为单位的团队用 squash；提交本身有复查价值（每步可独立回滚）的用 rebase merge；merge commit 留给真正的集成分支。三种混用会让 git log --graph 变成抽象画——选一种，全仓库统一。

三、强推边界与历史改写许可

第 2 章黄金法则的制度化表述，逐条划界：

1. 主干与共享长命分支：任何 force push 一律禁止（平台直接关掉权限）。
2. 个人功能分支：允许 rebase 后强推，但必须用 --force-with-lease。
3. 多人间共用的集成分支：禁止改写；需要撤回用 revert（第 3 章 3.3 的公共历史法则）。

配套一条沟通常规：功能分支被大幅 rebase 后，在群里（或任务单里）说一句"已变基，请重新 checkout"——引用被改写的信息越早广播，同事的困惑越少。这条软规则比任何技术护栏都更能减少团队内耗。

四、发布与热修流程范本

把 4.3 的标签发布扩成完整流程。常规发布：功能全部合入主干 → CI 全绿 → 负责人打附注标签（tag -a vX.Y.Z -m "..."）→ 点名推送标签 → 平台从标签构建产物 → 在任务系统登记发布记录。热修走快车道：从最新发布标签拉 hotfix 分支 → 最小修复 → 补测试 → 评审合并回主干 → 主干上打递增修订号标签。热修的关键纪律是双向回流：修复必须进主干（否则下个版本丢修复），Gitflow 场景还要回流 develop。

清理例行：每周由值班者执行幽灵分支清理（平台删除已合并分支，本地 fetch --prune）、悬空标签核对（ls-remote 对账）、以及主干的 ahead/behind 异常检查。清理不是洁癖——第 4 章讲过引用列表是共享导航图，导航图长满杂草，新人的第一周就在迷路。

五、规范的最小可行版本

不要试图一次写出一部法典。给新团队的起步包只有五条：主干受保护禁直推；变更走功能分支（类型斜杠简述编号）；合并需一人批准加 CI 绿；个人分支强推仅限 force-with-lease；发布打附注标签并点名推送。跑一个月，把实际踩到的坑（冲突频发点、命名混乱点）逐条增补。规范的生命力来自修订记录——把规范文档本身放进仓库用 Git 管理，每次修订一个提交，谁改的、为什么改，历史即审计。

⚠️ 常见坑：规范写得比代码还厚，无人阅读无人执行。判断一条规则该不该存在，看它防的事故是否真的发生过或概率显著；防"想象中事故"的规则，三个月后连制定者自己也说不清缘由。

还有一句直觉值得记牢：好规范都是对象模型约束的翻译——禁止强推是保护共享引用，短命分支是控制 merge-base 距离，squash 是控制主干上的提交粒度，标签发布是钉住不可变快照。理解了第 1 到 4 章的机制，你不仅能执行规范，还能在团队演进时自己修订规范。

本节要点回顾

• 命名三纪律：类型前缀挂编号、人名不进分支名、合并即删。
• 保护集：禁直推、批准数、CI 门禁，平台层锁死引用更新权。
• 合并方式三选一并统一：squash 求净、rebase 求细、merge 求真。
• 强推边界：主干绝不、个人分支 force-with-lease、集成分支用 revert。
• 规范起步包五条：从最小集开始按事故驱动增补，规范自身入库纳管。

最后一节清点武器库——平台、图形工具与命令行加速配置。