选择 Git Flow 和 Trunk-Based 开发 (TBD) 之间的选择会显著影响您的 CI/CD 工作流程。以下是快速概述：
- Git Flow: 适合于结构化、版本控制的环境。它使用多个分支，如
main,develop,feature,release和hotfix。适合于大型团队、较慢的发布周期和严格的 QA 流程。 - 主干式开发: 以单个主干为中心,使用短暂的功能分支。适合小型团队、快速发布和强大的自动化测试。
快速比较:
| 方面 | Git Flow | 主干式开发 |
|---|---|---|
| 分支复杂度 | 多个长期分支 | 单个分支,短暂分支 |
| 发布频率 | 预定发布 | 持续部署 |
| 团队规模 | 大型团队 | 中小型团队 |
| 测试 | 周期末测试 | 自动化测试 |
| 部署风险 | 使用分阶段发布时降低 | 频繁更新时风险更高 |
| 回滚 | 较慢 | 较快 |
主要 takeaway: 使用 Git Flow 进行结构化的、较慢的工作流程，使用 TBD 进行速度和灵活性。两者都需要坚实的 CI/CD pipeline 才能成功。
29 - GitFlow 与 Trunk-Based Development: 管理 …
Git Flow Workflow 基础
Git Flow 使用五种分支类型来组织开发： 主分支, 开发分支, 特性分支, 发布分支
Git Flow Branch Structure
| Branch Type | Purpose | Merge Target |
|---|---|---|
| Holds production-ready code | ||
| Integrates features; serves as the base for feature branches | Holds production-ready __CAPGO_KEEP_0__ | N/A |
| 功能 | __CAPGO_KEEP_0__用于构建单独的功能;从develop创建 | develop |
| 发布 | __CAPGO_KEEP_0__为最终测试和版本准备;从develop创建 | main & develop |
| 热修复 | __CAPGO_KEEP_0__快速修复生产问题;从main创建 | main & develop |
Git Flow优势
- __CAPGO_KEEP_0__允许同时开发多个功能而不导致冲突。
- Release branches 提供了一个专门的空间来进行最终测试和版本准备，保持 develop branch
- Hotfix branches
Git Flow 的缺点
- Branch Management Complexity: 管理多个活跃分支会使合并变得更加困难。
- Slower Deployment: 正式发布流程可能会比更简单的工作流慢一些。
- Increased Maintenance: 每个分支都需要自己的管道配置，这会增加维护工作量。
适合需要严格版本控制、多个发布轨迹或遵守法规的项目。接下来，我们将探讨如何将此与流水线开发的简化方法进行比较。
分支式开发基础
分支式开发（TBD）围绕一个单一的主分支，通常称为主干或主分支。这种方法与 DevOps 实践和持续集成密切相关。
分支式开发分支结构
在典型的 TBD 工作流中，您将遇到以下分支类型：
| 分支类型 | 目的 | 生命周期 |
|---|---|---|
| 主/主干 | Central branch with production-ready code | 永久 |
| 功能分支 | 用于单独变更的临时 branch | 短暂的 |
| 发布 Branches | 用于发布前的最后调整 | 临时的 |
开发人员经常将小的、增量的变更合并到主 branch 中 - 经常在一天内多次。 这鼓励持续测试并帮助快速解决冲突。
Trunk-Based Benefits
TBD 为 CI/CD 和 DevOps 工作的团队带来了几个优势:
- 较少的合并冲突: 定期合并冲突可管理。
- : 自动化构建在每次合并时运行，早期捕捉错误。: 自动化构建在每次合并时运行，早期捕捉错误。
- __CAPGO_KEEP_0__简化管道
- : 单一 branch 减少 CI/CD 设备的复杂性。更好的团队协作
: 共享的树干确保每个人都保持一致。
这种结构创建了一个流线化的工作流程，为下一节与 Git Flow 进行比较做好准备。
树干基于限制
| 虽然 TBD 有其优势，但它也带来了挑战，团队需要解决: | 挑战 | 影响 |
|---|---|---|
| Code Stability | 稳定性风险：可能的破坏性更改影响主干 | 使用强大的自动化测试 |
| 团队协调 | 重叠的工作可能会导致中断 | 依赖于特性标志和频繁的小型提交 |
| 学习曲线 | 从长期分支过渡 | 提供培训并逐渐过渡 |
| 规模问题 | 频繁的合并可能会淹没大型团队 | 严格执行code的详细审查 |
成功采用 TBD 需要坚实的自动化测试和团队内部的开放沟通
Git Flow 与 Trunk-Based 的直接比较
Git Flow 和 Trunk-Based Development 在关键方面的对比：
特性比较表
| 方面 | Git Flow | Trunk-Based Development |
|---|---|---|
| 分支复杂度 | 多个长期分支 | 单个主分支，短期分支 |
| 发布频率 | 预定的发布 | 持续部署 |
| 团队大小 | 适合较大团队 | 更适合较小的团队 |
| Code 代码审查流程 | 分支合并时进行正式的代码审查 | 持续审查小的、频繁的代码变更 |
| 测试需求 | 关注周期末的测试 | 依赖自动化测试 |
| 学习曲线 | 由于多个 branch 而变得更加复杂 | 更简单的工作流程，但需要强大的测试 |
| 部署风险 | 降低风险的分阶段发布 | 更高风险的频繁更新 |
| 恢复时间 | 较慢的回滚过程 | 更快的恢复能力 |
使用每种工作流程的时机
Git Flow 适合企业级项目，需要结构化的版本发布。它适合管理多个支持版本和具有正式QA或合规需求的项目。
分支式开发 适合优先考虑速度和灵活性的团队和项目，例如：
- 需要快速更新的SaaS平台
- 具有强大CI/CD管道的团队
- 基于可靠的自动化测试的项目
- 持续部署工作流或频繁发布
- 需要定期更新的移动应用程序项目
一些团队甚至将这两种方法结合起来：使用Trunk-Based Development为核心服务，Git Flow为具有正式发布跟踪的项目
下一步：如何设置CI/CD管道以支持两种方法
CI/CD管道设置
Git Flow CI/CD设置
- 开发分支管道: 运行单元测试、集成测试、code质量检查、构建验证和部署到开发环境
- 发布分支管道: 执行完整的测试套件、安全扫描、构建发布候选版本并部署到预发布环境
- 主分支管道执行验证测试、处理版本、创建生产构建、部署到生产环境并打上发布标签。
主干CI/CD设置
- 特性分支管道快速单元测试、code风格检查、构建验证和预览环境部署。
- 主分支管道涵盖全面自动化测试、安全扫描、生产构建创建、渐进式部署和自动回滚功能。
Capgo CI/CD集成
要在CI/CD设置中添加实时的即时更新功能，Capgo可以无缝整合：
Capgo与 GitHub Actions, GitLab CI, 和 Jenkins 以便在 Git Flow 和 Trunk-Based pipeline 中启用实时更新、分阶段发布和即时回滚。它满足了 Apple 和 Google 的要求，同时支持云和自主部署 [1].
概要和建议
根据您的团队大小和 CI/CD 成熟度水平选择您的工作流程，以下表格提供参考:
| 场景 | Git Flow | Trunk-Based |
|---|---|---|
| 团队大小 | 50+ 开发人员 | 少于 50 开发人员 |
| 发布频率 | 每周或每月 | 每天或多次每天 |
| 测试与QA | 传统QA周期 | 重点自动化测试 |
| 部署模型 | 多版本传统 | 云原生容器化 |
| 风险承受度 | 保守的受管控设置 | 进步的快速反馈 |
- 在较小的团队中开始使用分支式开发，随后扩展到更大的团队。确保在过渡之前，CI/CD pipeline完全自动化。
- 在两种工作流中都使用特性开关，保持一致的code评分。将管道配置与所选的工作流程对齐。
有些团队可能会混合使用这些方法 - 使用Git Flow进行重大发布，同时利用分支式开发进行特性交付。无论您走哪一条路，成功都依赖于正确地集成CI/CD，自动化测试，并且让团队保持一致。
