Git 分支策略：小团队别照抄大厂那套

很多团队的分支规范是从别处抄来的：五条长期分支、四个环境、一堆 release 流程。

结果通常是：规矩写在文档里，实际没人遵守；合并冲突越积越多；上线前一天不敢合并。

问题不在规矩本身，在于规矩和团队规模不匹配。

一、三人以下：GitHub Flow（短分支 + 主干随时可发布）

只有一条长期分支（main），每条改动开一个短分支，提 PR，合并后立刻部署。

main       ●────●────────●────●
            \  /          \  /
feature      ●─●            ●─●

规则只有四条：

1. main 永远处于可发布状态

2. 改动走分支 + PR，不直接推 main

3. 分支活不过两天

4. 合并前 CI 必须绿

为什么适合小团队： 沟通成本低，不需要层层审批。所有人都在同一份 main 上，冲突能第一时间发现。

什么时候会撑不住： 当出现“这个功能已经开发两周但还不能上线”时。这时候需要第二条分支。

二、五到十五人：加一条发布分支

出现下面任一情况，就该引入 release 分支：

• 有功能开发到一半、但不能随下一个版本上线
• 需要给线上版本打补丁，同时 main 还在加新东西

main      ●───●───●───●───●───●
           \       \     /
release     ●───●───●───●

做法：

1. 到发布点，从 main 拉一条 release/x.y 分支

2. 测试、修 bug 在 release 分支上做

3. 上线后把 release 的修复合并回 main（这一步最容易漏，漏了就会在下一个版本重新踩同一个坑）

4. 打 tag

关键纪律：修 bug 必须回 main。 只在 release 分支上修、不回主干的团队，三个月后会发现两个分支已经无法合并。

三、超过十五人或多产品线：才需要 Git Flow 那套

Git Flow 的五条分支（main、develop、feature、release、hotfix）本质是为了并行维护多个已发布版本。

如果你的产品只有一条线上版本，用 Git Flow 只会增加负担：

• 所有人都要从 develop 拉分支，develop 又常常落后于 main
• 两个长期分支之间的合并冲突是常态
• 新人要花一周才能搞懂每天该从哪条分支切

判断标准很简单： 你现在需要给三个以上已发布版本同时打补丁吗？如果不需要，就不要用 Git Flow。

四、比分支策略更重要的一条

分支策略解决不了“主干长期不可发布”的问题。真正有效的是三条工程纪律：

1. 功能开关（feature flag）代替长期分支。

一个功能要开发两周？合并进 main，但用开关关着。这样代码天天在主干上跑 CI，不会积累冲突。

2. 小而频繁的 PR。

一个 PR 改 30 个文件、500 行，评审质量必然下降。控制在 200 行以内，评审才有意义。

3. 每次合并都验证。

CI 只跑单测不够。至少要有一次真实的启动验证，否则“CI 绿了但服务起不来”会成为常态。

五、切换时机的信号

不用纠结“我们现在是几阶段”，看症状更准：

症状 | 说明 | 该做什么

合并冲突天天有 | 分支活太久 | 缩短分支寿命

上线前要“封版一周” | 主干不可发布 | 上功能开关 + 缩小 PR

修了 bug 下个版本又出现 | 补丁没回合主干 | 强制回 main

两条分支无法合并 | 已经开始分裂 | 停手砍分支，合并回一条

新人一周上不了手 | 流程太重 | 精简流程

小结

分支策略不是越完整越好，是越匹配越好。

• 三人以下：短分支 + 主干可发布，够了
• 五到十五人：加一条 release
• 更复杂才考虑多长期分支

而且真正决定交付质量的，从来不是分支模型，而是主干是否随时可发布。这一条做到了，用什么分支策略都活得下去；做不到，什么模型都救不了。