Git 分支模型：Git Flow 与主干开发

分支策略没有标准答案，它本质上是「发布节奏」与「团队协作方式」的映射。

Git Flow：分支各司其职

main      ────●──────●──────   生产分支，只接受合并
hotfix        ─●─              线上紧急修复
release         ──●─           发布准备与回归
develop   ──●──●──●──●──────    集成分支
feature      ─●─●─             功能开发

适合版本化发布的产品：客户端、私有化交付、按周期上线的系统。优点是职责清晰、线上永远可回滚；代价是合并成本高，分支存活期长冲突就多。

主干开发（Trunk-Based）

所有人向 main 提交，小步合并，特性用开关（feature flag）控制是否生效。适合持续部署的互联网服务。

main   ●─●─●─●─●─●─   每个点都可发布
          └short branch┘  生存期 ≤ 2 天

它的前提很硬：自动化测试、CI 必须可靠，否则半成品代码直接进主干，等于人人天天踩坑。

怎么选

GitHub Flow 是两者的中间态：main 始终可发布，功能走短命分支 + PR，合并即部署。多数 Web 项目从它开始最合适。

与分支策略无关的三条纪律

1. 分支生存期越短越好。超过一周的 feature 分支，合并成本指数上升；
2. rebase 与 merge 的选择要统一。团队内约定一种，历史才可读；
3. 保护主干。main 禁止 force push，合并前 CI 必须绿——分支策略的可靠性最终取决于对主干的保护强度。

切分支前的检查只有一句：这个分支的寿命打算多长？答案超过三天，就该拆分任务。