Trunk-Based Development（TBD）和Git Flow不是“选哪个更好”，而是“谁在什么约束下能少踩坑”。 你团队当前的发布节奏、CI/CD成熟度、成员协同习惯，直接决定哪种策略实际可用——而不是文档里写得漂亮。
Trunk-Based Development 要求「每次提交都可集成」
TBD 的核心不是“只用一个分支”，而是“所有人在 main 上持续提交，且每次提交后 CI 必须通过”。它不禁止分支，但禁止长期存活的特性分支；允许存在 feature/xxx 分支，但生命周期应控制在几小时到 1 天内，合并前必须 rebase 到最新 main 并通过全部检查。
- CI 流水线必须能在 5 分钟内完成构建 + 单元测试 + 静态扫描，否则
main会卡住 - 不允许“先合再修”：一旦
git push到main触发失败，必须立刻修复或回退，不能等别人来救 - 没有
develop分支，也就没有“开发环境稳定但未上线”的中间态——main就是开发态，也是集成态 - 线上 hotfix 直接改
main，再git cherry-pick到对应v1.2等 release tag 所在的发布分支（如果存在）
Git Flow 在「发布节奏固定+人工卡点」场景下仍有实用价值
Git Flow 不是过时，而是对协作节奏和流程控制有明确前提：你需要 release/1.3 分支做 UAT 验收、需要 hotfix/1.2.5 单独打包补丁、需要开发人员不直面生产代码压力。它的代价是分支数量多、合并冲突频发、develop 分支容易偏离真实集成状态。
-
feature分支若超过 3 天未合并，大概率出现CONFLICT (content): Merge conflict in src/utils.js -
release分支从develop切出后，若develop继续合入新功能，会导致release无法干净合回 —— 这时只能手工挑 commit 或放弃自动合并 -
hotfix合并回develop时，常因基线差异导致逻辑被覆盖（例如develop已重写同个函数，而hotfix的修复被 git 认为“已解决”） - 它默认假设“测试是串行的”：SIT → UAT → 上线。如果你们实际是并行灰度+AB 测试，Git Flow 的分支命名和流向反而制造理解负担
别忽略「团队规模」对分支策略的实际压制作用
5 人以下团队用 Git Flow，大概率演变成“所有人只动 develop，没人管 release 和 hotfix”；15 人以上团队硬推 TBD，若没有强制的 pre-commit hook + 自动化 gate + 每日冒烟机制，main 会在第 3 天变成不可部署状态。
- 团队中若有 2 人以上不熟悉
git rebase -i或不敢操作git push --force-with-lease，TBD 就不具备落地基础 - 如果 CI 每次跑 20 分钟，且没有「跳过非关键 job」的灵活配置，TBD 下每人每天平均等待时间会超过 1.5 小时
- Git Flow 中
feature分支命名若不统一（如有人用feat/login，有人用feature_login_v2），git branch --merged和自动化清理脚本会失效
真正难的不是选策略，而是承认：TBD 要求工程能力前置，Git Flow 要求流程纪律前置。两者都做不到时，“轻量级 Git Flow”（仅保留 main 和 feature/*，用 git tag 替代 release 分支）反而是最不容易失控的起点。
