在 Git Flow 和 Trunk-Based Development (TBD) 之间做选择，会显著影响你的 CI/CD 工作流。快速拆解如下：
- Git Flow：最适合结构化、版本控制严格的环境。它使用多个分支，例如
main,develop,feature,release，以及hotfix。适合大型团队、发布周期较长以及 QA 流程严格的场景。 - 基于主干的开发模式 (Trunk-Based Development)：专注于单一主分支和短生命周期的功能分支。适合小型团队、快速发布节奏以及强大的自动化测试。
快速对比：
| 维度 | Git Flow | 基于主干的开发模式 (Trunk-Based Development) |
|---|---|---|
| 分支复杂度 | 多个长期分支 | 单分支，短生命周期分支 |
| 发布节奏 | 按计划发布 | 持续部署 |
| 团队规模 | 大型团队 | 中小型团队 |
| 测试 | 周期末测试 | 自动化测试 |
| 部署风险 | 分阶段发布，风险较低 | 频繁更新，风险较高 |
| 回滚 | 较慢 | 更快 |
核心要点：使用 Git Flow 实现结构化、较慢的工作流，使用 TBD 追求速度和灵活性。两者都需要可靠的 CI/CD pipeline 才能成功。
29 - GitFlow vs. 主干开发：管理…
Git Flow 工作流基础
Git Flow 使用五种分支类型来组织开发： main, develop, feature, 发布版，以及 hotfix. 这种结构有助于高效管理版本发布和并行开发。
Git Flow 分支结构
| 分支类型 | 用途 | 合并目标 |
|---|---|---|
| 主要 | 存放生产就绪的 code | 不适用 |
| Develop | 集成功能；作为功能分支的基础 | 不适用 |
| 功能 | 用于开发单个功能；从 develop 分支创建 | develop |
| 发布 | 为最终测试和版本发布做准备；从 develop 分支创建 | main & develop |
| Hotfix | 快速修复生产问题；从 main 分支创建 | main & develop |
Git Flow 的优势
- 允许同时开发多个功能，且不会产生冲突。
- Release 分支为最终测试和版本准备提供专用空间，同时保持 develop 分支开放，以便持续开发。
- Hotfix Hotfix 分支可以快速解决生产问题，而不会中断其他开发任务。
Git Flow 的缺点
- 分支管理复杂: 管理多个活跃分支会让合并更具挑战性。
- 部署速度较慢: 相比更简单的 workflow，正式发布流程可能会拖慢部署速度。
- 维护成本增加：每个分支都需要独立的 pipeline 配置，增加了维护工作量。
这种工作流最适合需要严格版本控制、多条发布轨道或满足合规要求的项目。接下来，我们会看看它与更精简的 Trunk-Based Development 方法相比如何。
Trunk-Based Development 基础知识
Trunk-Based Development (TBD) 以单一的主分支（通常称为 trunk 或 main）为核心。这种方法与 DevOps 实践和持续集成高度契合。
Trunk-Based 分支结构
在典型的 TBD 工作流中，你会遇到以下几种分支类型：
| 分支类型 | 用途 | 生命周期 |
|---|---|---|
| 主分支/Trunk | 包含生产就绪 code 的中央分支 | 永久性 |
| 功能分支 | 用于单个变更的临时分支 | 生命周期短 |
| 发布分支 | 用于发布前的最终微调 | 临时性 |
开发者会定期将小型的增量变更合并到主分支——通常每天多次。这有助于持续测试，并帮助快速解决冲突。
Trunk-Based 的优势
对于使用 CI/CD 和 DevOps 的团队，TBD 具有以下优势：
- 更少的合并冲突: 定期合并让冲突保持可控。
- 更快的反馈：每次合并都会运行自动化构建，及早发现 bug。
- 更简单的 Pipeline：单一分支降低了 CI/CD 配置的复杂度。
- 更好的团队协作：共享主干确保团队步调一致。
这种结构形成了精简的工作流，为下一节与 Git Flow 的对比奠定了基础。
Trunk-Based 的局限性
虽然 TBD 有其优势，但也伴随着团队需要应对的挑战：
| 挑战 | 影响 | 如何应对 |
|---|---|---|
| Code 稳定性 | 破坏性变更影响主分支的风险 | 使用强大的自动化测试 |
| 团队协作 | 重叠的工作可能导致干扰 | 依赖功能标志和频繁的小提交 |
| 学习曲线 | 从长期分支过渡 | 提供培训并逐步实施 |
| 扩展性问题 | 频繁合并可能让大型团队不堪重负 | 强制进行彻底的 code 审查 |
成功采用 TBD 需要扎实的自动化测试和团队内部的开放沟通。
Git Flow vs. Trunk-Based：直接对比
以下是 Git Flow 与 Trunk-Based 开发在关键方面的对比：
功能对比表
| 维度 | Git Flow | 基于主干的开发模式 (Trunk-Based Development) |
|---|---|---|
| 分支复杂度 | 多个长期分支 | 单一主分支，配合短期分支 |
| 发布节奏 | 按计划发布 | 持续部署 |
| 团队规模 | 适合大型团队 | 更适合小型团队 |
| Code 审查流程 | 分支合并时的正式审查 | 持续审查小而频繁的变更 |
| 测试要求 | 侧重周期末测试 | 高度依赖自动化测试 |
| 学习曲线 | 因多分支而更复杂 | 工作流更简单，但需要强大的测试 |
| 部署风险 | 分阶段发布降低风险 | 频繁更新风险更高 |
| 恢复时间 | 回滚流程更慢 | 更快的回滚能力 |
何时使用每种工作流
Git Flow 非常适合需要结构化、版本化发布的企业级项目。对于管理多个受支持版本、且有正式 QA 或合规需求的团队和项目来说，也非常合适。
基于主干的开发模式 (Trunk-Based Development) 最适合重视速度与灵活性的团队和项目，例如：
- 需要快速迭代的 SaaS 平台
- 拥有完善 CI/CD pipeline 的团队
- 有可靠自动化测试保障的项目
- 持续部署工作流或高频发布
- 需要定期更新的移动 App 项目
有些团队甚至会结合使用这两种方法：核心服务采用 Trunk-Based Development，而具有正式发布流程的项目则使用 Git Flow。
下一篇：如何为这两种模式配置 CI/CD pipeline。
CI/CD Pipeline 配置
Git Flow CI/CD 配置
- 开发分支 Pipeline: 运行单元测试、集成测试、code 质量检查、构建验证，并部署到开发环境。
- 发布分支 Pipeline: 执行完整测试套件、安全扫描、构建 Release Candidate，并部署到 Staging 环境。
- 主分支流水线: 执行验证测试、管理版本、创建生产构建、部署到生产环境，并为发布打标签。
Trunk-Based CI/CD 配置
- 特性分支流水线: 侧重快速单元测试、code 风格检查、构建验证，以及部署到预览环境。
- 主分支流水线: 涵盖全面的自动化测试、安全扫描、创建生产构建、渐进式部署和自动回滚功能。
Capgo CI/CD 集成
要在任一 CI/CD 配置中添加实时空中更新，Capgo 可无缝集成：
Capgo 支持 GitHub 操作, GitLab CI，以及 Jenkins 在 Git Flow 和 Trunk-Based 流水线中启用实时更新、分阶段发布和即时回滚。它满足 Apple 和 Google 的要求，同时支持云端和自托管部署 [1].
总结与建议
根据团队规模和 CI/CD 成熟度，使用下表选择适合的工作流：
| 场景 | Git Flow | 主干开发 |
|---|---|---|
| 团队规模 | 50+ 名开发者 | 少于 50 名开发者 |
| 发布频率 | 每周或每月 | 每天或每天多次 |
| 测试与 QA | 传统 QA 周期 | 专注于自动化测试 |
| 部署模式 | 多版本，传统模式 | 云原生、容器化 |
| 风险容忍度 | 保守、受监管的环境 | 渐进式、快速反馈 |
- 小团队先从 Trunk-Based Development 开始，再扩展到更大的团队。切换前，确保 CI/CD pipeline 已完全自动化。
- 在两种工作流中都要保持一致的 code review，并使用 feature toggles。pipeline 配置要与所选工作流保持一致。
有些团队可能会混用这些方法——用 Git Flow 做重大版本发布，同时用 Trunk-Based Development 做功能交付。无论选哪条路，成功都取决于是否正确集成 CI/CD、实现测试自动化，并让团队保持步调一致。
继续阅读：Git Flow vs Trunk-Based for CI/CD
如果你正在使用 面向 CI/CD 的 Git Flow 与 Trunk-Based 对比 规划 CI/CD 自动化，并将其与 Capgo CI/CD 集成 用于 Capgo CI/CD 中的产品工作流， Capgo Native Build 用于 Capgo Native Builds 中的产品工作流， Capgo 集成 用于 Capgo 集成中的产品工作流， CI/CD 集成 了解 CI/CD 集成的实现细节，以及 GitHub Actions 集成 有关 GitHub Actions 集成的实现细节。
