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