Git 分支策略：何时使用 Git Flow，何时只用 main
一个项目有了 Git，下一步通常就会冒出这个问题：要不要建develop？要不要为每次发布建release/*？出了线上问题是不是必须开hotfix/*？
很多团队把 Git Flow 当成标准答案，于是从第一天开始维护一串长期分支。结果是，每次修改都要思考“该从哪里拉、该合到哪里、是否还要回合另一条线”，真正交付功能的时间反而变少。
Git Flow 是一套很好的发布管理模型，但它不是所有项目的默认工作流。选择分支策略时，真正该问的不是“哪一种更专业”，而是：我们的发布、维护和协作，是否已经复杂到需要这些分支？
结论先行
对个人项目、小团队和持续交付应用，优先使用main+ 短生命周期任务分支。只有在多版本维护、发布冻结或大型并行协作确实存在时，才引入完整 Git Flow。
Git Flow 解决的是什么问题
Vincent Driessen 在 2010 年提出的 Git Flow，把“开发下一版本”“准备发布”“修复线上版本”拆到不同分支上。它的核心价值是让这些不同节奏的工作不会互相踩踏，而不是创造更多分支。
图片直接引用 A successful Git branching model；
| 分支 | 服务的工作 | 为什么需要它 |
|---|---|---|
main | 已发布、可交付的版本 | 任何时候都能定位一个可靠版本 |
develop | 下一版本的集成 | 不影响已发布版本地汇集新功能 |
feature/* | 独立开发一项功能 | 隔离未完成的改动 |
release/* | 冻结功能、测试、发布准备 | 发布修复不干扰下一版本开发 |
hotfix/* | 紧急修复线上问题 | 从已发布版本快速修复，并把修复回流 |
这套模型很适合“软件有明确版本号、要维护多个已安装版本、发布前有长测试窗口”的场景。例如桌面软件、SDK、企业内网软件或需要长期支持的客户端应用。
一个重要的更新：作者也不建议到处套用
Git Flow 的作者在 2020 年为原文补充了反思：如果团队持续交付 Web 应用，通常应采用更简单的流程，例如 GitHub Flow，而不是强行把 Git Flow 套进去。查看原文后记
原因很现实：持续交付的服务通常只运行一个线上版本，功能完成、测试通过后就能部署。此时长期develop分支并没有解决新的问题，却多引入了一次集成和一次合并风险。
流程会产生维护成本
每增加一条长期分支，就增加一条需要同步、合并、检查和解释的路径。流程本身应当消除真实风险，而不是成为“看起来规范”的负担。
大多数项目的默认解：main加任务分支
对多数个人项目与小型协作项目，最小但足够的策略是：main始终可运行，所有相对独立的工作在短期分支完成，验证后再合回main。
| 场景 | 推荐分支 | 完成后的动作 |
|---|---|---|
| 单个小修正、文档更新 | 直接在main | 提交并推送 |
| 新功能 | feat/简短主题 | 合入main后删除分支 |
| 缺陷修复 | fix/简短主题 | 合入main后删除分支 |
| 风险较高的验证 | experiment/简短主题 | 合入或直接删除 |
| 正式版本节点 | 不建release/* | 在main对应提交打 tag |
它的重点不是“少建分支”，而是只保留有明确职责的分支。任务完成后删除分支，历史由提交和版本标签保存，而不是靠保留无用的长期分支。
用三个问题选择策略
下面的判断比背诵任何工作流名称都更可靠：
适合完整 Git Flow 的信号
- 需要同时支持
v1.x、v2.x等多个仍在使用的版本。 - 发布不能随时进行，存在功能冻结、回归测试、审批或灰度周期。
- 线上紧急修复必须从某个已发布版本精确分叉。
- 团队规模和并行功能较多，集成工作需要长期独立于发布分支。
应当保持轻量的信号
- 只有一个正在运行或维护的版本。
- 每次合并到
main都可以部署，或者可以很快验证后部署。 - 项目由个人或少量成员维护。
- 发布只是给一个稳定提交打标签，而不是漫长的独立阶段。
[!tip] 可以渐进升级
轻量流程并不意味着永远不能有release/*。当一次具体发布确实需要冻结和集中测试时，临时建立 release 分支即可；当这个需求变成常态，再把它固化为长期流程。
两种策略的日常操作差异
轻量策略把日常复杂度压缩到一次任务分支的生命周期：
gitswitch maingitpull --ff-onlygitswitch-cfeat/export-data# 开发、提交、测试gitswitch maingitmerge --no-ff feat/export-datagitbranch-dfeat/export-datagittag v1.2.0# 仅在需要发布时完整 Git Flow 则要求额外维护develop，发布分支需要同时回合main和develop，线上修复也要回流到未来版本。它的收益是发布管理更严谨；代价是每一次合并都要更明确地确认目标分支。
因此，流程升级的正确顺序是：先让main保持可靠、让提交可读、让任务分支及时清理；只有这些实践不足以解决发布问题时，再增加更多结构。
比分支数量更重要的三件事
无论采用哪种模型，下列实践通常比“选 Git Flow 还是 GitHub Flow”影响更大：
main可用。合入主线前至少完成与改动相称的验证；不要让主分支长期堆放半成品。- 提交可读。一次提交表达一项清楚的变化，采用一致的
feat:、fix:、docs:等格式。详见 [[Git 提交规范]]。 - 分支有终点。功能分支不是新的永久栖息地；完成、合并、删除，让仓库始终保持低认知负担。
GitHub 的仓库最佳实践同样建议常规协作者在同一仓库内通过分支和 Pull Request 协作，而不是彼此 Fork；对main等重要分支可使用保护规则与检查来守住质量。阅读 GitHub 文档
从今天开始的最小行动
不必为现有项目重建所有分支。下一项稍大的改动开始时，只做下面四步：
- 更新
main：git pull --ff-only。 - 新建
feat/你的主题或fix/你的主题。 - 在合并前运行测试，并检查提交内容。
- 合回
main后删除任务分支；需要发布时再打标签。
这足以让项目从“所有事情都在主线同时进行”走向可预测的维护节奏。等到项目真的面临多版本或发布冻结，再把 Git Flow 的相应部分加进来，而不是提前背负整套流程。
进一步阅读
- Vincent Driessen：A successful Git branching model
- Atlassian：Gitflow Workflow
- 【Git 基础命令】从混乱到稳定的日常工作流
