选择 Git Flow 和分支式开发（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 与 Trunk-Based Development: 管理 …
Git Flow 工作流程基础
Git Flow 使用五种分支类型来组织开发: __CAPGO_KEEP_0__, __CAPGO_KEEP_0__, __CAPGO_KEEP_0__, __CAPGO_KEEP_0____CAPGO_KEEP_0__ 和__CAPGO_KEEP_0__
. 这种结构有助于有效地管理发布和并行开发。
| Git Flow 分支结构 | 分支类型 | 目的 |
|---|---|---|
| 主分支 | code已准备就绪 | N/A |
| 开发 | 集成特性，作为特性分支的基础 | N/A |
| 特性 | 用于构建单个特性，基于开发分支创建 | 开发 |
| 发布 | 准备最终测试和版本化，基于开发和主分支创建 | 主分支 & 开发 |
| 紧急修复 | 快速修复生产问题;基于主分支创建 | 主分支 & 开发分支 |
Git Flow 优势
- 允许同时开发多个功能而不造成冲突。
- 发布分支提供了一个专门的空间用于最终测试和版本准备,保持 开发 分支开放用于持续工作。
- 紧急修复 分支使快速修复生产问题变得容易,而不会中断其他开发任务。
Git Flow 缺点
- 分支管理复杂性: 多个活跃分支的管理会使合并变得更加困难。
- Slower Deployment: 相比于更简单的工作流程，正式发布流程可能会降低部署速度。
- Increased Maintenance: 每个分支都需要自己的管道配置，这会增加维护工作量。
This workflow works best for projects that need strict version control, multiple release tracks, or compliance with regulations. Up next, we’ll explore how this compares to the streamlined approach of trunk-based development.
Trunk-Based Development Basics
Trunk-Based Development (TBD) revolves around a single main branch, often called the trunk or main. This approach aligns closely with DevOps practices and continuous integration.
Trunk-Based Branch Structure
In a typical TBD workflow, you’ll encounter these branch types:
| Branch Type | Purpose | 生命周期 |
|---|---|---|
| 主干/主干 | 生产就绪的中心分支,code | 永久 |
| 功能分支 | 用于个别变更的临时分支 | 短暂 |
| 发布分支 | 用于发布前的最后调整 | 临时 |
开发人员经常将小的、增量式的更改合并到主分支中 - 经常在一天内进行多次。这鼓励持续测试并帮助快速解决冲突。
主干式开发的好处
TBD 为 CI/CD 和 DevOps 工作的团队带来了几个优势:
- 减少冲突: 定期合并冲突可控。
- 更快的反馈: 自动构建在每次合并时运行，尽早捕捉错误。
- 更简单的管道: 单个 branch 减少了 CI/CD 设计的复杂性。
- 更好的团队协作: 共享的 trunk 确保每个人都保持一致。
这种结构创建了一个流线化的工作流程，为下一节与 Git Flow 进行比较做了准备。
分支树的局限性
虽然 TBD 有其优势，但它也带来了团队需要解决的问题：
| 挑战 | 影响 | 如何解决 |
|---|---|---|
| Code 稳定性 | 可能的破坏性更改影响主分支 | 使用强大的自动化测试 |
| 团队协调 | 重叠的工作可能会导致中断 | 依赖于特性标志和频繁的小型提交 |
| 学习曲线 | 从长期存活的分支过渡 | 提供培训并逐渐过渡 |
| Scaling Issues | 大型团队中频繁合并代码可能会造成问题 | 严格执行 code |
成功采用 TBD 需要团队内部的开放沟通和自动化测试
Git Flow 与 Trunk-Based 开发的直接比较
Git Flow 和 Trunk-Based 开发在关键方面的对比
特性比较表格
| 方面 | Git Flow | Trunk-Based 开发 |
|---|---|---|
| Branch 复杂度 | 多个长期分支 | 单一主分支与短命分支 |
| 发布频率 | 预定发布 | 持续部署 |
| 团队规模 | 适合较大的团队 | 更适合较小的团队 |
| Code 代码审查流程 | 正式代码审查 | 持续审查小的、频繁的代码变更 |
| 测试要求 | 关注周期末的测试 | __CAPGO_KEEP_0__ |
| 学习曲线 | __CAPGO_KEEP_1__ | 由于多个 branch 而更复杂 |
| 更简单的工作流程，但需要强大的测试 | __CAPGO_KEEP_2__ | 发布风险 |
| 使用分阶段发布降低风险 | 频繁更新会带来更高的风险 | 恢复时间 |
更慢的回滚过程
更快的恢复能力 __CAPGO_KEEP_0__适合企业级项目，需要结构化的版本发布。它适合管理多个支持版本和项目的团队，以及具有正式QA或合规需求的项目。
Trunk-Based Development __CAPGO_KEEP_0__适合优先考虑速度和灵活性的团队和项目，例如：
- 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 动作, GitLab CI, 和 Jenkins 以便在 Git Flow 和 Trunk-Based pipeline 中启用实时更新、分阶段发布和即时回滚。它满足了 Apple 和 Google 的要求，同时支持云和自主部署 [1].
概要和建议
根据您的团队大小和 CI/CD 成熟度水平选择您的工作流程，以下表格提供参考:
| 场景 | Git 流 | 主干式 |
|---|---|---|
| 团队规模 | 50+ 名开发者 | 少于 50 名开发者 |
| 发布频率 | 每周或每月 | 每日或多次每日 |
| 测试 & QA | 传统 QA 周期 | 重点自动化测试 |
| 部署模型 | 多版本传统 | 云原生，容器化 |
| 风险承受度 | 保守，受管制的设置 | 进步，快速反馈 |
- 在小型团队中从事分支式开发，随后扩展到大型团队。确保在过渡之前您的CI/CD管道完全自动化。
- 保持一致的code审查，并在两种工作流程中使用特性开关。将管道配置与所选的工作流程对齐。
一些团队可能会混合使用这些方法 - 使用Git Flow进行重大发布，同时利用分支式开发进行特性交付。无论您走哪一条路，成功都取决于正确地集成CI/CD，自动化测试，并确保团队保持一致。
