团队里关于分支的讨论通常停在「Git Flow 更正规」和「GitHub Flow 更快」这两句话上，但分支模型并不存在通用最优解，它只是把团队的发布节奏写进了版本库。先看三个决定因素，再谈选型。

Git 分支策略：Git Flow 与 GitHub Flow 怎么选 示意图

先看三个决定因素

  • 发布频率：一天多次上线，和一季度一次大版本，需要的分支结构完全不同；
  • 并行版本数：是否需要同时维护 1.x 与 2.x，甚至给客户单独出补丁；
  • 回滚要求：出问题时要能整包回退到上一个 tag，还是关掉一个开关就行。

Git Flow：为多版本并行而生

它把分支生命周期拆成五类：main 常驻生产、develop 集成日常提交、feature 承载单个需求、release 冻结待发布内容、hotfix 用于线上急救。分支名带上需求号，方便和看板互相追溯：

git switch -c feature/1024-order-export develop
git switch -c release/2.3.0 develop
git switch -c hotfix/login-timeout main

代价是分支数量多、合并路径长。release 冻结期间在 main 上修的 bug，必须再合回 develop，一旦纪律松散就会出现「develop 与 main 内容不一致」的经典问题。它适合有明确版本号、需要长期维护多个版本的产品。

GitHub Flow：一条 main 加短分支

规则只有两条：main 始终可发布；所有改动走短分支加 Pull Request，合并即部署。分支存活时间以小时计，冲突面积小。代价是对自动化测试要求高——没有 CI 与灰度，合并就等于上线。

git switch -c fix/cart-total main
git fetch origin
git rebase origin/main
git push -u origin fix/cart-total

主干开发：把分支压到最短

主干开发（Trunk Based Development）进一步要求所有人直接向 main 提交小颗粒改动，未完成的功能用特性开关（feature flag）隐藏，而不是长期留在分支上。它对工程能力要求最高，但也是持续交付团队常见的最终形态。

判断分支模型是否合适，只看一个指标：一个改动从提交到上线平均需要多久。超过两天的，多半是流程而不是代码在拖后腿。

绕不开的保护规则

  • main 与 release 设为保护分支，禁止直接 push；
  • 合并前必须通过 CI、至少一个 review，并要求分支与目标分支已同步；
  • 发布用 tag 标记，不要依赖「记住某个 commit」，回滚时才有明确锚点；
  • 合入长期分支时用 --no-ff 或 squash，避免历史被切成碎片。

小结

小团队、单版本、每日发布，直接用 GitHub Flow；多版本并行、有客户定制分支，才值得引入 Git Flow；等 CI 足够稳、回滚靠开关而不是靠 revert 时，再迁移到主干开发。合并方式本身的细节，可以接着看rebase 与 merge 的区别。