每次团队讨论 Git 工作流，场面都很热烈。有人搬出 Git Flow 的严谨分支模型，有人推荐 Trunk-Based Development 的极简主义，还有人觉得 GitHub Flow 够用就行。辩论往往持续一个下午，最后投票选一个，README 里写上规范，全员执行。

然后三个月后你会发现：分支还是乱成一锅粥，release 分支上堆了二十个 cherry-pick，hotfix 从 master 拉出来合不回去，有人偷偷开了 feature branch 三周没合，还有人在 master 上直接 commit——"就改了一行，没必要开分支"。

工作流选错了？不，工作流没选错。是大部分团队在选工作流的时候，选的是自己向往的工作方式，而不是自己实际具备的发布能力。

Git Flow：为发布窗口而生的妥协

Vincent Driessen 在 2010 年提出 Git Flow 的时候，他的假设非常明确：你的软件有固定的发布周期。develop 分支积累功能，release 分支冻结测试，master 分支只放生产代码，hotfix 从 master 拉出紧急修复。每一步都有清晰的语义。

这个模型流行起来的根本原因不是它"好"，而是它适配了大多数团队的现实——发布频率低，发布窗口固定，线上出了问题需要紧急修复但不能影响正在开发的功能。金融、电商、企业软件，这些行业的发布节奏天然适合 Git Flow。

但 Git Flow 的问题也很明显：分支模型重，合并成本高，feature branch 存活时间长导致冲突风险剧增。一个 feature 开发两周，期间 develop 已经前进了几十个 commit，合回来的时候光解冲突就能花半天。

所以很多团队开始嫌弃 Git Flow，觉得它笨重、过时，转而拥抱更"现代"的工作流。问题是，Git Flow 的笨重不是它的问题，是你的发布频率的问题。如果你一个月才发一次版，你的分支就必然是长生命周期的，不管你用什么工作流。

GitHub Flow：CI/CD 的入场券

GitHub Flow 比 Git Flow 简单得多：master 永远可部署，所有开发在 feature branch 上进行，通过 PR 合入 master，合入即部署。没有 release 分支，没有 hotfix 分支，紧急修复也是从 master 拉分支走 PR。

这套流程看起来清爽，但它有一个硬性前提——你的 CI/CD 必须足够快、足够可靠。PR 合入 master 之后，自动化测试要能快速验证，部署流程要能在几分钟内完成。如果你的 CI 跑一趟要四十分钟，部署还要人工审批，那合入即部署就是空谈。

我见过不少团队宣称自己在用 GitHub Flow，实际上是"GitHub Flow 的壳，Git Flow 的魂"：feature branch 合入 master 之后，并不会立刻部署，而是等一个"发布窗口"统一上线。那 master 和 develop 有什么区别？没有区别。你只是把分支名字从 develop 换成了 master，流程的本质没变。

GitHub Flow 的本质不是一种分支策略，而是一种发布能力的声明：我们有能力在任意时刻安全地发布 master 上的代码。如果你做不到这一点，用 GitHub Flow 就是在自欺欺人。

Trunk-Based Development：需要对齐的不只是工作流

Trunk-Based Development（TBD）是当前"先进工程实践"的代表：所有人都在主干（trunk/main）上开发，feature branch 存活不超过一天，用 feature flag 控制未完成功能的暴露，频繁集成，频繁发布。

听起来很美。但 TBD 的前提条件清单长得吓人：

自动化测试覆盖率高，且执行速度快——主干上的每次提交都要跑测试，如果测试套件跑一个小时，没人愿意频繁集成。Feature flag 基础设施完善——未完成的功能必须能被 flag 遮挡，不影响其他功能的运行和测试。这不仅是加个 if-else 的事，flag 的管理、清理、灰度策略都需要体系支撑。小批量开发文化——一个需求拆成多个小 PR，每个 PR 独立可测试、可部署。这对产品经理的需求拆分能力有很高要求，不是团队能单方面决定的。部署自动化和回滚能力——出了问题能快速回滚，而不是靠 revert 分支慢慢操作。

Google、Meta 这些公司能做 TBD，不是因为他们的工程师更厉害，而是他们花了十几年建这套基础设施。Facebook 的 Phabricator、Google 的内部代码审查和自动测试体系，这些都是 TBD 的地基。大部分团队连 CI 跑到绿灯都费劲，就让开发者往主干上直接推代码，结果只能是主干频繁红灯，最后谁都不敢推了。

工作流和能力的不匹配才是真正的灾难

比选错工作流更可怕的，是工作流和实际能力的不匹配。这种不匹配会以一种隐蔽的方式侵蚀团队效率。

最常见的场景：团队名义上用 GitHub Flow，实际上 feature branch 存活一周以上，PR 堆积如山，合并冲突此起彼伏。开发者被要求"小步提交、频繁合并"，但 CI 太慢导致反馈滞后，feature 开发到一半发现跟主干的差异已经大到难以合并。最后大家被迫在 feature branch 上频繁 rebase，每天都在解冲突。

还有一种情况：团队信誓旦旦要转 TBD，把所有 feature branch 砍掉，要求大家往主干上提交。但没搞 feature flag，未完成的功能全部暴露在主干上。测试环境里到处是半成品功能，QA 分不清哪些是 bug 哪些是还没做完的功能。线上发布时手忙脚乱地注释代码，或者用配置开关东遮西掩。

在金融业务场景中，这种不匹配的风险更高。合规要求意味着某些变更必须经过审批才能上线，风控规则要求灰度发布必须有回滚方案，业务要求部分功能在特定时间窗口统一开放。这些约束不会因为你选了 TBD 就消失。如果工作流和这些硬约束不兼容，最后一定会在某个环节被打回原形。

我见过一个团队，技术负责人力推 TBD，花了一个季度搞 feature flag 体系，又花了一个季度推动小 PR 文化。结果到了大促期间，为了赶进度，几个核心需求还是在长生命周期的分支上开发，合入主干的时候出了两次线上事故。大促结束后，没人再提 TBD，默默回到了 Git Flow。

不是 TBD 不好，是时机没到。发布能力的建设跟不上工作流的升级，最后就是倒退。

工作流是能力的结果，不是原因

理解了这一点，很多争论就不必要了。你不应该先选一个工作流再让团队去适应，而是应该先看自己的发布能力在哪个层级，然后选择与之匹配的工作流。

如果你的发布频率是一周一发甚至更低，CI 跑一次要半小时，部署需要申请审批，没有 feature flag 基础设施——那你就是在 Git Flow 的能力区间。老老实实用 Git Flow，把 release 分支管理好，hotfix 流程理清楚，别追求什么"先进工作流"。

如果你的 CI 能在十分钟内跑完，部署流程自动化但不是全自动，发布频率可以做到一天一次——GitHub Flow 是合适的。重点建设自动化测试和部署流水线，而不是纠结分支命名规范。

如果你的 CI 五分钟以内，部署全自动且可回滚，feature flag 体系成熟，团队能做到小批量开发——可以尝试 TBD。但即使能力到位了，TBD 也不是必选项，它是一种可选的优化，不是一种必达的标准。

这里有一个很关键的判断：工作流的切换应该是发布能力提升后的自然结果，而不是能力提升的驱动力。先建 CI/CD，再考虑切 GitHub Flow；先建 feature flag 体系和小 PR 文化，再考虑切 TBD。顺序反了，就是在拿团队效率赌一个美好的愿景。

还有一个被忽略的维度：团队规模

工作流的适用性不仅和发布能力相关，还和团队规模强相关。

五人团队用 TBD 很轻松，因为沟通成本低，谁在做什么大家都知道，主干冲突少。五十人团队用 TBD，需要的不只是自动化测试和 feature flag，还需要模块化的代码所有权、细粒度的测试隔离、更严格的提交规范——成本指数级上升。

Git Flow 在小团队里显得笨重，两个人开发还要切 develop、feature、release 多个分支，管理成本远大于收益。但在大团队里，Git Flow 的分支语义提供了明确的协作边界——release 分支冻结时只有 bug fix 能进去，master 分支永远和线上一致，这些约定降低了大规模协作的沟通开销。

所以同样一个工作流，在不同规模的团队里表现完全不同。很多"最佳实践"之所以水土不服，根本原因就是忽视了团队规模这个变量。

别再为工作流吵架了

每次看到团队花一个下午辩论 Git 工作流，我都觉得可惜。不是因为这个话题不重要，而是因为大部分团队的瓶颈根本不在工作流选型上。

你的发布卡在审批流程上，你的 CI 要跑四十分钟，你的测试覆盖率不到 30%，你的 feature 分支平均存活两周，你的部署还需要运维手动操作——这些问题和用 Git Flow 还是 TBD 没有半点关系。换一个工作流，这些问题照样存在，只不过换了一种方式折磨你。

真正值得花时间做的事情：

把 CI 速度优化到十五分钟以内——这是所有工作流升级的前提。在 Git Flow 下，快的 CI 意味着 release 分支的验证周期短，hotfix 的验证速度快。在 TBD 下，快的 CI 是频繁提交的基本保障。建设自动化部署能力——不管用什么工作流，部署自动化都是刚需。区别只在于 Git Flow 的部署通常跟随发布节奏，而 TBD 的部署需要更频繁。推动小批量开发文化——这不是技术问题，是产品和工程协作的问题。需求拆得小，feature branch 才存得短，合并冲突才少，不管用哪种工作流都受益。建立 feature flag 基础设施——这是从"定时发布"到"随时发布"的关键桥梁。没有 feature flag，你的主干永远不能包含未完成的功能，这就注定了你必须用长生命周期的分支来隔离开发中的代码。

这些事情做完了，该用哪种工作流是显而易见的。做不完，换哪种工作流都是在换汤不换药。

说到底，Git 工作流选择反映的不是技术品味，而是工程成熟度。你选的不只是一种分支策略，而是对自己发布能力的一次诚实评估。做不到诚实评估，选什么都白搭。