为什么需要分支策略

一个人写代码时，直接在 main 上提交就够了。但团队多人并行开发，问题立刻出现：谁都往同一条线上推，昨天刚发的版本被今天的半成品带崩，合并时还要面对一大堆互相覆盖的冲突。

分支策略要解决的，其实是三个问题：大家在哪里并行、怎么合回去、出了问题怎么快速退回来。策略不是 Git 的高级技巧，而是团队约定——定得清楚，每个人都知道该从哪里切分支、合到哪里去。

分支用得乱，不是 Git 的错，是团队没有约定好怎么用它。
本文核心知识点
  • 主线永远是一条可随时发布的稳定线。
  • 短分支分支活得越短，合并冲突越少。
  • 门禁合入主干前必须过评审与自动检查。
  • 可回滚出问题能分钟级退回上一个版本。
  • 匹配策略要匹配团队规模与发布节奏，不追新潮。
Git 分支策略示意：蓝色渐变背景上一条发光水平主线分出多条上下岔路并在明亮节点处汇合，像发光的版本分叉合并路径，扁平科技插画
主干负责稳定，分支负责并行，节点就是一次次评审通过的合并。

GitHub Flow：一条主线加短分支

GitHub Flow 是最容易上手的一套：main 永远可发布，每个改动都开一个短命分支，做完就合回去。规则简单到能贴在墙上。

# 一次典型的 GitHub Flow 循环（命令为示意）
从最新 main 切一个新分支：
  git switch -c feature/购物车优惠券

在这个分支上小步提交、随时推送备份：
  git commit -m "加上满减规则"

推送后发起合并请求，请人评审、跑 CI：
  git push -u origin feature/购物车优惠券

评审与检查都通过后合回 main，删掉这条分支：
  git merge feature/购物车优惠券
  git branch -d feature/购物车优惠券

它的关键不是流程本身，而是分支活不久：一个分支几天内就合回去，改动面小，冲突少，回滚也容易。适合持续发布的产品团队。

Trunk Based：小步直奔主干

比 GitHub Flow 更激进的是 Trunk Based：开发者几乎直接往主干提交，只是把一个完整的大改动拆成很多小步，每步都能独立合并上线。没做完的部分用开关藏起来，而不是用长分支藏起来。

做法短分支（GitHub Flow）主干直推（Trunk Based）
并行方式一人一条短分支大家在主干上小步前进
未完成功能留在分支里用特性开关先藏起来
前提评审与 CI 成熟测试与自动化极成熟
适合多数中小团队高成熟度、超高频发布团队

Trunk Based 换来的是几乎没有「合并地狱」的代价，但它对自动化测试和特性开关的要求很高，不是想上就能上。

功能分支与发布分支怎么取舍

还有一类做法是同时维护长期的功能分支和发布分支：功能在 feature 分支上开发，准备上线时切出 release 分支做最后修整，再合回主干并打版本标签。

  • 适合需要按月、按版本发版，且要同时维护多个旧版本的团队（比如客户端、有线下交付的软件）。
  • 代价是分支数量多、生命周期长，合并冲突和「为什么这个版本没带上那个修复」会变多。

取舍原则很朴素：发版节奏越频繁，越应该用短分支或主干直推；越需要长期维护多个并行版本，才越需要发布分支。