选择 Git Flow 或 Trunk-Based 开发（TBD）将显著影响 CI/CD 流程。以下是快速概述： Git Flow 和 Trunk-Based 开发（TBD）之间的选择将显著影响 CI/CD 流程。以下是快速概述：
- Git Flow: 最适合结构化、受版本控制的环境。它使用多个分支，如
main,develop,feature,release和hotfix。适合大型团队、缓慢的发布周期和严格的QA流程。 - ,Git Flow
: 集中在一个主要分支上，短暂的特性分支。适合小型团队、快速发布和强大的自动化测试。
| 快速比较： | 方面 | Git Flow |
|---|---|---|
| Trunk-Based Development | 分支复杂度 | 多个长期分支 |
| 发布频率 | 预定发布 | 持续部署 |
| 团队规模 | 大型团队 | 中小型团队 |
| 测试 | 周期末测试 | 自动化测试 |
| 部署风险 | 使用分阶段发布时较低 | 频繁更新时风险较高 |
| 回滚 | 较慢 | 较快 |
主要 takeaway: 使用 Git Flow 进行结构化的、较慢的工作流程，使用 TBD 进行速度和灵活性。两者都需要坚实的 CI/CD pipeline 才能成功。
29 - GitFlow 与 Trunk-Based Development: 管理 …
Git Flow 工作流程基础
Git Flow 使用五种分支类型来组织开发： main, 开发, 功能, 发布, 和 修复. 这种结构有助于有效地管理发布和并行开发。
Git Flow Branch 结构
| Branch 类型 | 目的 | 合并目标 |
|---|---|---|
| 主 | 持有生产就绪的 code | N/A |
| 开发 | 集成特性，作为特性分支的基础 | N/A |
| 特性 | 用于构建单个特性，创建于开发 | develop |
| 发布 | 准备最终测试和版本化，创建于开发 | main & develop |
| 热修复 | 快速修复生产问题，创建于main | 主开发 |
Git 流优势
- 允许同时开发多个功能而不引起冲突。
- 发布分支为最终测试和版本准备提供了一个专门的空间，保持 开发 分支开放进行持续工作。
- 热修复 分支使快速解决生产问题变得容易而不会中断其他开发任务。
Git 流缺点
- 分支管理复杂性: 管理多个活跃分支会使合并更加困难。
- 更慢的部署: formal发布流程可能会降低与更简单的工作流程相比的部署速度。
- 增加的维护: 每个分支都需要自己的管道配置，这会增加维护工作量。
这种工作流程适用于需要严格版本控制、多个发布轨迹或遵守法规的项目。接下来，我们将探讨如何将这种方法与流线化的trunk-based开发方法进行比较。
Trunk-Based开发基础
Trunk-Based开发（TBD）围绕一个单独的主分支，通常称为树干或主分支。这一方法与DevOps实践和持续集成非常接近。
Trunk-Based分支结构
在典型的TBD工作流程中，您将遇到以下分支类型：
| 分支类型 | 目的 | 生命周期 |
|---|---|---|
| 主/树干 | 中央分支，生产就绪的code | 永久性 |
| 功能分支 | 用于个别变更的临时分支 | 短暂的 |
| 发布分支 | 用于发布前的最后调整 | 临时的 |
开发人员经常将小的、增量的变更合并到主分支中 - 经常在一天内进行多次。这鼓励持续测试并帮助快速解决冲突。
分支式开发的好处
TBD 为 CI/CD 和 DevOps 工作的团队带来了几个优势：
- 减少冲突次数: 合并冲突可控。
- 更快的反馈: 自动化构建在每次合并时运行，早期捕捉bug。
- 更简单的管道: 单个 branch 减少了 CI/CD 配置的复杂性。
- 更好的团队协作: 共享 trunk 确保每个人保持一致。
这种结构创建了一个流畅的工作流程，设置了与 Git Flow 的下一节的比较。
分支主干的局限性
虽然 TBD 有其优势，但它也带来了团队需要解决的问题：
| 挑战 | 影响 | 如何解决冲突 |
|---|---|---|
| Code 稳定性 | 主分支上的破坏性更改风险 | 使用强大的自动化测试 |
| 团队协调 | 重叠的工作可能会导致中断 | 依赖特性标志和频繁的小型提交 |
| 学习曲线 | 从长期分支过渡 | 提供培训并逐渐过渡 |
| 规模化问题 | 频繁的合并可能会淹没大型团队 | 严格执行 code 的审查 |
成功采用 TBD 需要团队内部的自动化测试和开放的沟通
Git Flow 与 Trunk-Based 的直接比较
Git Flow 和 Trunk-Based 开发在关键方面的对比
特性比较表格
| 方面 | Git Flow | Trunk-Based 开发 |
|---|---|---|
| Branch 复杂度 | 多个长期分支 | 单个主分支，短期分支 |
| 发布频率 | 定期发布 | 持续部署 |
| 团队大小 | 适合较大的团队 | 更适合较小的团队 |
| Code 审核流程 | 正式的分支合并审核 | 持续审核小的频繁变更 |
| 测试要求 | 关注周期末测试 | 依赖自动化测试 |
| 学习曲线 | 由于多个 branch 的关系，更加复杂 | 虽然流程更简单，但需要强大的测试 |
| 部署风险 | 通过分阶段发布降低风险 | 频繁更新会带来更高的风险 |
| 恢复时间 | 回滚过程较慢 | 更快的恢复能力 |
使用每种工作流程的时机
Git Flow 适合企业级项目，需要结构化的版本发布。它适合管理多个支持版本的团队，以及具有正式QA或合规需求的项目。
基于分支的Trunk Development 适合优先考虑速度和灵活性的团队和项目，例如：
- SaaS 平台需要快速更新
- 拥有强大 CI/CD pipeline 的团队
- 依赖可靠自动化测试的项目
- 持续部署工作流或频繁发布
- 需要定期更新的移动应用项目
有些团队甚至结合了这两种方法：使用 Trunk-Based Development 为核心服务和 Git Flow 为具有正式发布跟踪的项目
接下来：如何设置 CI/CD pipeline 以便采用任意一种方法
CI/CD Pipeline 设置
Git Flow CI/CD 设置
- 开发分支 pipeline：运行单元测试、集成测试、code 质量检查、构建验证和部署到开发环境。
- Release Branch Pipeline: 执行完整的测试套件、安全扫描、生成发布候选版本并部署到测试环境。
- Main Branch Pipeline: 进行验证测试、处理版本号、创建生产版本、部署到生产环境并打上发布标签。
Trunk-Based CI/CD Setup
- : 特性分支管道: 快速执行单元测试、code 风格检查、构建验证和预览环境部署。
- Main Branch Pipeline: 全面自动化测试、安全扫描、生产版本创建、渐进式部署和自动回滚功能。
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管道完全自动化。
- 保持一致的code评分并在两种工作流程中使用特性开关。将管道配置与所选的工作流程对齐。
一些团队可能会混合使用这些方法 - 使用Git Flow进行重大发布，同时利用分支式开发进行特性交付。无论您走哪一条路，成功都取决于正确地集成CI/CD，自动化测试，并确保团队保持一致。
继续Git Flow vs Trunk-Based for CI/CD
如果您正在使用 Git Flow vs Trunk-Based for CI/CD 来规划CI/CD自动化，连接它与 Capgo CI/CD 用于产品工作流程在Capgo CI/CD, Capgo 原生构建 为产品工作流程中的 Capgo 原生构建, Capgo 集成 为产品工作流程中的 Capgo 集成, CI/CD 集成 CI/CD 集成的实现细节, 和 GitHub 动作集成 为 GitHub 动作集成的实现细节。
