分支策略怎么定？主干开发、Git Flow 与发布分支
围绕主干开发、Git Flow 与发布分支三种做法，按发布节奏、并行版本和维护成本建立选择标准，并给出 Web/SaaS、套装软件、多版本合规维护与小团队的落地建议，附分支规则、热修复路径和工具支撑。
分支一多，合并冲突就多；发布前冻结主干，开发又开始等。很多团队把问题归咎于版本控制工具，其实更该先看发布节奏、版本负担和自动化能力。用 GitFox 管代码时，受保护分支和合并门禁可以强制执行，但分支模型仍要按发布约束来定。
主干开发、Git Flow 与发布分支没有脱离场景的唯一答案，关键是把发布约束和团队能力对上。下面按共同标准比较，再给出条件化选择。
分支策略先看发布节奏：发布越频繁，长期分支越少
先问三个问题：发布节奏是每天多次、每周一次，还是按季度或客户现场升级？版本负担是只维护一个线上版本，还是要同时维护多个？自动化能力是否足以承接高频合并？
发布越频繁、并行版本越少，长期分支的合并成本越突出；并行版本越多、稳定窗口越长，发布分支的隔离价值越明显。分支策略要服务这些约束。
主干开发、Git Flow 与发布分支，各管什么
主干开发：合并快，但测试必须跟得上
主干开发把开发集中到一条 trunk，Git 中通常叫 main。团队仍可开短生命周期分支做评审和构建检查，但要尽快合回；较长需求用功能开关或分支抽象隔离，而不是保留几周不合并的开发线。trunkbaseddevelopment.com 的概括是：围绕单一主干协作，避免其他长期开发分支；持续集成要求成员至少每 24 小时向主干提交一次。发布时可按需切发布分支，一些团队也会直接从主干发布，并用向前修复处理缺陷。
代价是自动化门槛高。主干必须长期可构建、可测试；合并前要有快速 CI、评审和足够测试。缺少这些，低合并成本会变成低质量代码快速扩散。
Git Flow：版本多、发布稳，但合并路径长
Git Flow 由 Vincent Driessen 在 2010 年提出。它保留 master 与 develop 两条长期分支：功能分支从 develop 切出并合回；发布前切 release 分支，做版本号、缺陷修复和稳定化；发布后合入 master 并打标签，同时合回 develop；线上紧急问题从 master 切 hotfix，再合回 develop 或当前发布分支。
它适合多个功能并行、发布需要冻结、版本还要可追溯的团队。代价是合并路径多：release 与 hotfix 都要回合并，规则执行不到位时，修复可能只进了发布分支，主干仍有同样缺陷。
发布分支：只稳住要交付的版本
发布分支不是完整 Git Flow，而是在主干之外，为某个即将交付的版本建立稳定线。微软 Azure DevOps 的分支指南建议，接近发布时从主分支创建 release 分支，缺陷修复通过拉取请求进入；同时把修复移植回主分支。Azure DevOps 团队采用主线优先：先在主线修改，再 cherry-pick 到发布分支。
它适合“主干继续开发，已发布版本还要稳定一段时间”的团队。关键纪律是修复单向流动：先在主干修，再摘取到发布分支；发布分支不接新功能，版本停止维护后删除。否则它会变成第二条开发主线。
差别不在分支数量，而在长期分支承担了多少发布隔离职责。
分支管理的关键：分支越多，维护成本越高
只看定义容易选错。把三种策略放进同一张表，比较集成批次、发布控制和维护负担，差异更直观。
| 维度 | 主干开发 | Git Flow | 发布分支 |
|---|---|---|---|
| 集成频率 | 每天多次，分支很短 | 功能完成后合入 develop | 主干持续集成，发布分支只接收修复 |
| 长期分支 | 通常只有主干 | master、develop 和多个 release | 主干 + 按版本存在的 release |
| 发布方式 | 从主干或临时发布分支 | 经 release 稳定化后发布 | 从 release 发布并打标签 |
| 主要成本 | 测试、评审、功能开关 | 合并路径多，规则维护重 | 版本越多，维护分支越多 |
| 适合场景 | 持续交付的 Web/SaaS | 多版本、固定节奏的套装软件 | 需要稳定窗口和并行维护版本 |
最容易被低估的是主要成本。主干开发把成本前移到测试和评审；Git Flow 把成本放在合并与流程维护；发布分支把成本放在版本管理和修复移植。团队哪一环更成熟，选择就向哪边倾斜。
Git 工作流怎么选：按场景，不按流行度
持续交付的 Web/SaaS，默认从主干开发开始。 不需要长期稳定线时，直接从主干发布；需要几天稳定窗口时，切短期 release，修复从主干 cherry-pick。
套装软件、私有化交付、嵌入式项目，优先发布分支。 客户升级慢、多个版本同时维护时，主干继续开发，release/版本号 承担稳定与补丁发布。是否需要完整 Git Flow，取决于是否真的需要独立 develop；很多团队用“主干 + 发布分支 + 热修复”已经够用。
版本并行多、审批链长的组织，可借用 Git Flow 的分支职责，但不必保留全部长期分支。 若 CI 和功能开关已能控制风险，多一条 develop 往往只增加合并次数。
10～50 人的小团队，不要先上重流程。 一条主干、短分支、强制评审和自动化测试更容易执行；等出现多版本维护或发布窗口，再引入发布分支。
版本控制工具先立规矩：合并规则定清楚，再谈分支模型
选定模型后，先做五件事：
- 保护主干：禁止直接推送，合并必须经过评审和 CI；紧急通道也要留审计记录。
- 限制分支寿命：功能分支按天计，超过约定时长自动提醒；长需求拆小或用功能开关隐藏。
- 把质量门禁放进合并前：编译、单测、静态扫描和必要的集成测试不通过，不允许合并。
- 固定修复路径：生产缺陷先在主干复现和修复，再 cherry-pick 到发布分支；无法复现时才在发布分支修复，并立即回合并、补测试。
- 让版本可追溯：每次发布打不可变标签，记录制品版本、发布分支和审批人；发布分支停止维护后归档再删除。
发布分支只承接稳定化与必要修复，不承接新功能。
分支规则还要落到版本控制工具和交付平台上。GitFox 作为禅道 DevOps 的内置核心组件，以自研底层引擎提供代码托管与分支管控、代码评审和CI/CD 流水线，并把制品版本放进同一链路；项目侧由禅道管理需求、任务和 Bug，GitFox 负责代码到发布的执行，底层不依赖海外开源内核。对 50～300 人的研发中心，这种组合能把受保护分支、合并门禁、构建与制品版本变成同一套规则；私有化部署和操作审计也适合金融、政企、军工等数据边界敏感的场景。工具不替团队做选择，但能把选择变成可检查的约束。
分支策略常见问题：几个容易选错的地方
主干开发是不是所有人都直接提交 main？ 不是。小团队可以直接提交，但多数团队仍用短生命周期分支做评审和 CI。关键不是有没有分支，而是分支是否很快合回主干，以及主干是否始终可发布。
小团队有必要上 Git Flow 吗？ 通常没有必要。只有一个线上版本、发布频繁时，主干开发加发布标签更轻。只有出现固定发布窗口或多个版本并行维护，完整 Git Flow 的额外分支才有明确收益。
发布分支修完 Bug 要合回主干吗？ 推荐先在主干修复，再 cherry-pick 到发布分支，避免主干漏修。只有在主干无法复现时，才在发布分支修复，并立即回合并、补测试和记录原因。
分支策略多久复盘一次？ 不按固定周期拍脑袋，按信号复盘：合并冲突持续增加、发布等待变长、热修复频繁漏回主干、维护分支失控，都是调整信号。可用 DORA 的部署频率、变更前置时间、变更失败率和服务恢复时间观察变化，但不要把指标当唯一目标。
先定发布约束，再选分支模型。版本控制工具里的分支图只是结果；能被稳定执行、审计和复盘的策略，比一个看起来标准的名字更重要。
