先记住这个答案
判断核心是发布周期和需要长期支持的版本数。若每天多次部署且只维护最新版，用 Trunk-Based 让所有提交尽快集成到主干，靠特性开关控制发布。若每季度发布且同时维护 2-3 个历史大版本，用 Git Flow 保留独立的 release 分支和 hotfix 分支，方便定点修复。不要盲目跟风，先量化这两个变量。
- 频发发布选Trunk-Based
- 多版本并行选Git Flow
- 特性分支生命周期要短
两种分支模型的核心机制差异
Git Flow 的核心是常驻多分支：master 保持可发布状态，develop 汇集功能，feature/* 从 develop 切出并合回，发布时从 develop 拉出 release/*，验证后并入 master 且打 tag。hotfix/* 直接基于 master 修复线上问题。
Trunk-Based 则只有一个高信任的 main 或 trunk，所有开发者的提交尽量直接合入它，通常采用短命名的特性分支（几小时到几天）或通过特性开关直接推送，配合 CI 全量测试使主干始终可部署。机制差异决定了集成节奏和分支存活时间。
一个具体场景：每周发布的 Web 应用团队
一个 Web 应用团队每周五发布一次到生产，同时维护最近两个大版本的热修（v1.0 和 v1.1）。他们最初用 Git Flow，每周从 develop 拉 release/*，但开发周期后期大量合并冲突，且线上热修的代码需要分别合并到 master、release 和 develop，导致重复劳动，人力消耗严重。
团队改为基于主干开发：日常功能用短分支合入 main，每次发布直接由 main 打 tag。当需要修复 v1.0 时，从对应 tag 切出 hotfix-1.0.x，修复后单独发布并合回 main。预期合并冲突减少约七成，发布节奏稳定在每周一至两次。
适用边界与失效条件
Git Flow 的失效边界：当发布频率高到每周多次时，develop 与 main 的差距在短期内会越拉越大，每次发布前从 develop 切 release 的分支创建和后续合并成本急剧上升，此时强制用 Git Flow 反而延长集成周期。
Trunk-Based 的失效边界是并行维护版本过多且修复必须反补主干。如果同时维护超过三个旧版本，每次热修都要在不同 tag 上反复合并，除非接受在每个旧版本上重复修，否则需要更长生命周期的维护分支，这已超出纯 Trunk-Based 的范畴。
容易答错的地方
- 认为 Trunk-Based 不需要代码评审
- Trunk-Based 不等于直接推代码到主干，仍需 Pull Request 或短分支配合评审，只是分支生命周期必须控制在几天内。若省略评审直接推送，会降低代码质量，反而违背主干可部署目标。
- 认为 Git Flow 必须有 develop 分支
- Git Flow 在小型团队或发布不频繁的项目中可简化：去掉常驻
develop，只保留master和临时feature分支，能减少无谓合并。照搬全套多分支结构会让多数场景白白付出合并成本。
面试官还会怎么问？
采用 Trunk-Based 如何保证主干稳定？
需要强自动化测试与特性开关：不完整功能用开关隐藏，合入前必须跑全量测试，并禁止直接 push 到主干，用短暂分支加评审合并。
多版本并行时有没有折中方案？
可用主干开发新特性，对旧版本用支持分支维护，但避免长期存在多个 release 分支。折中的本质是限定热修窗口，比如只修最近两个大版本。
特性开关的维护成本有多高？
需要按版本计划清理过期开关，否则代码中积累死逻辑。但换来的收益是每天都能合入代码，降低集成冲突。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。