2.1 版本控制与分支策略

2.1 版本控制与分支策略

本节摘要：版本控制是发布之旅的起点，分支策略则是团队协作的"交通规则"。本节从 Git 的对象模型讲到主流分支模型（主干开发、Git Flow、GitHub Flow、GitLab Flow）的取舍，再讲合并请求与代码评审的流程设计。核心结论：分支策略没有最好的，只有与团队发布节奏匹配的；分支活得越久，合并越痛。

读完这节你能回答

1. 理解 Git 快照模型与分支的实质
2. 对比四种主流分支策略的适用场景与代价
3. 设计一套带质量门禁的合并请求流程
4. 写出对未来排障有价值的提交信息

一、为什么交通规则比车速重要

想象一条没有车道线的环路：每辆车都想到达目的地，但没有规则规定谁走哪条道、什么时候并线。结果是互相别车、大面积拥堵。分支策略就是代码协作的车道线——它规定变更从哪条"车道"进入主干、在路上要经过哪些"检查站"、多久必须"并线"一次。

版本控制工具本身（Git）只提供机制，不提供策略。同一个 Git，有的团队用得行云流水，有的团队用得怨声载道，差别全在策略。而策略失误的代价有很强的隐蔽性：出问题时它不报错，只是让所有人慢慢觉得"合并代码很可怕"、"发布日像拆弹日"。

先快速过一遍 Git 的基础认知，然后重点讲策略。

二、Git 的实质：快照与引用

Git 与上一代版本控制系统的根本区别：它存的是快照，不是差异。每次提交都记录当时整个项目的一份（逻辑上的）快照，提交之间通过父指针连成链。分支本质上只是一个指向某个提交的可移动指针——创建分支几乎零成本，这是 Git 区别于老式集中式工具的革命点，也是后来一切灵活分支策略的技术前提。

几个对协作行为有深远影响的机制值得点出。

合并的三种形态。快进合并（fast-forward）只是移动指针，不产生合并提交，历史线性干净；三方合并会产生一个合并提交，保留分叉事实；变基（rebase）把你的提交"摘下来"重放在目标分支顶端，历史看起来像从没分过叉。团队要统一约定用哪种——变基出漂亮的历史，但改写了提交，禁止对已推送的公共分支变基是铁律。

合并冲突不是 Git 的问题，是设计的问题。频繁出现冲突，说明变更批量太大或改动范围重叠管理失控，工具只是诚实地报告了这个事实。

提交的原子性。一次提交只做一件事——一个功能、一个修复、一次重构。原子提交是回滚友好、排障友好、评审友好的前提。把"修复登录超时"和"顺手升级了十个依赖"塞进同一个提交，是对未来排障者的一次坑害。

三、四种主流分支策略

主干开发（Trunk-Based Development）

所有开发者频繁（至少每天）向主干提交，未完成的特性用功能开关隐藏。这是持续交付语境下最受推崇的模型：分支存活时间以小时计，冲突几乎不可能积累，配合特性开关可以实现"代码先上、功能后开"。代价是纪律要求高：主干必须随时可发布，测试体系必须过硬，团队必须接受"半成品在主干里但被开关挡住"的心理门槛。它适合发布频繁、工程能力成熟的团队。

Git Flow：为版本发布而生

一个长期主干（master）加一个开发主线（develop），特性分支、发布分支、维护分支各司其职。它在"按版本周期发布"的年代设计合理，但分支数量多、存活时间长，与"随时可发布"的目标天然冲突。今天它主要还适合有明确版本号的客户端软件（移动应用、桌面软件）团队。

GitHub Flow：最简可用

主干加短期特性分支，评审合并后立即部署。只有一条规则：主干随时可部署。它简单到新成员五分钟能懂，适合 Web 服务团队的自然起步形态。局限是没有为"多环境停留"提供表达——代码合并后要么立刻上生产，要么没有明确状态。

GitLab Flow：加上环境分支

在 GitHub Flow 基础上增加环境分支（预发、生产），代码沿环境分支单向流动。它用一点复杂度换取了发布节奏的可控，适合"能持续构建、但发布要卡窗口"的团队，比如受监管的行业。

选型的判断题

与其问"哪个最好"，不如回答三个判断题。发布频率能否做到合并即上线？能，选主干开发或 GitHub Flow；不能但有固定发布节奏，选 GitLab Flow。是否需要同时维护多个线上版本？需要（如客户端多版本并存），Git Flow 仍有价值。团队工程纪律（测试覆盖、CI 时长）处于什么水位？水位低时强行主干开发，主干会被冲垮——先修 CI 再换策略。

一个常见误区是把策略当信仰。真实团队里混搭很正常：整体主干开发，但大重构用长生命周期的特性分支加每日反向合并。策略是工具，"短分支、小批量、频繁集成"的目标才是本体。

四、合并请求与代码评审

无论哪种策略，现代团队的变更进入主干前都要过"合并请求"这一关。一套运转良好的流程长这样。

检查站在合并之前。合并请求创建后，CI 自动跑静态检查、构建、测试；至少一名同行评审通过；关键模块需要指定负责人批准。这些门禁写成仓库保护规则，由平台强制执行——靠自觉的规则等于没有规则。

评审看什么。评审的首要价值不是抓 bug（测试更擅长），而是传播知识、维护标准、把关设计。一次健康的评审讨论的是"这个抽象是否合理、命名是否达意、有没有更简单的做法"，而不是逐行挑格式问题——格式问题应该交给自动化格式化工具。

小是美德。一个 200 行的合并请求能在半小时内得到高质量评审；一个 3000 行的合并请求会躺两天，最后被不耐烦地"扫一眼"通过。评审响应速度应作为团队的服务承诺（比如"四小时内首次响应"），否则特性分支会被迫延长寿命，回到长分支的老路。

# 仓库保护规则示例：主干分支的门禁
protect_rules:
  branch: main
  required_status_checks:
    - ci/lint            # 静态检查
    - ci/build           # 构建成功
    - ci/unit-tests      # 单元测试通过
    - ci/coverage-gate   # 覆盖率不低于基线
  approvals:
    minimum: 1
    require_code_owners: true   # 关键目录需负责人批准
  dismiss_stale_approvals: true # 新提交使旧批准失效
  block_force_push: true        # 禁止强推改写历史
​

五、提交信息：写给六个月后的自己

排障时最常问的问题是"这行代码为什么这么写、哪个需求改的"。答案在提交信息里——前提是它被认真写过。一份好的提交信息分两段：标题一行说"做了什么"（祈使句、不加句号），正文说"为什么这么做、有什么影响"。

标题：修复订单列表在高并发下的重复分页问题

正文：
分页查询使用 offset 且未加排序稳定字段，并发写入时
两页之间可能插入新记录，导致同一行在相邻两页重复出现。

改为按游标（最后一条记录的排序键）分页，并补充并发
场景的回归测试。影响面：订单列表接口，无数据库变更。
​

六个月后深夜排障的人（很可能是你自己）看到这条信息，可以立刻排除一半假设。写提交信息的成本是两分钟，收益可能是一次凌晨三点与早上九点的区别。

本节要点回顾

• Git 的实质：快照模型加可移动的分支指针，分支零成本是灵活策略的技术前提
• 冲突是信号：频繁冲突说明批量太大或改动范围失控，不是工具问题
• 策略四型：主干开发配功能开关适合高频发布；Git Flow 适合多版本客户端；GitHub Flow 极简起步；GitLab Flow 加环境晋升
• 选型三问：能否合并即上线、是否多版本并存、工程纪律水位如何
• 门禁写进规则：状态检查加批准人数由平台强制，评审重设计轻格式，小合并请求是美德
• 提交信息是排障资产：标题写做了什么，正文写为什么与影响面