选择 Git Flow 和 Trunk-Based Development (TBD) 可以显著影响您的 CI/CD 工作流。以下是快速概述：
- Git Flow: 适合结构化、版本控制的环境。它使用多个分支，如
main,develop,feature,release,和hotfix。适合大型团队、较慢的发布周期和严格的 QA 流程。 - Trunk-Based Development: 集中在一个主要分支上，短暂的功能分支。适合小型团队、快速发布、强大的自动化测试。
快速比较：
| 方面 | Git Flow | Trunk-Based Development |
|---|---|---|
| 分支复杂度 | __CAPGO_KEEP_0__ | __CAPGO_KEEP_0__ |
| 发布频率 | 预定发布 | 持续部署 |
| 团队规模 | 大型团队 | 小型到中型团队 |
| 测试 | 周期末测试 | 自动化测试 |
| 部署风险 | 与阶段发布一起降低 | 与频繁更新一起提高 |
| 回滚 | 较慢 | 较快 |
主要 takeaway: 使用 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 分支结构
| 分支类型 | 目的 | 合并目标 |
|---|---|---|
| Main | Holds production-ready code | 无 |
| 开发 | 集成特性，作为特性分支的基础 | 无 |
| 特性 | 用于构建单个特性，基于开发分支创建 | 开发 |
| 发布 | 准备最终测试和版本化，基于开发和主分支创建 | 主分支 & 开发分支 |
| 快速修复生产问题;基于main创建 | main & develop | Git Flow的优势 |
允许同时开发多个功能而不引起冲突。
- 发布分支为最终测试和版本准备提供了一个专门的空间，
- develop 分支保持开放状态，用于持续工作。 快速修复生产问题的
- 分支使得不打断其他开发任务轻松解决生产问题。 Git Flow的缺点
分支管理的复杂性
- __CAPGO_KEEP_0__: 多个活跃分支的管理会使合并变得更加困难。
- 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 审核流程 | 正式审核在分支合并时 | 持续审核小的频繁变更 |
| 测试要求 | 关注周期末测试 | 对自动化测试有过度依赖 |
| 学习曲线 | 由于多个 branch 而更复杂 | 更简单的工作流程，但需要强大的测试 |
| 部署风险 | 通过阶段发布降低风险 | 频繁更新会带来更高的风险 |
| 恢复时间 | 更慢的回滚过程 | 更快的恢复能力 |
使用每种工作流程的时机
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 设置中添加实时的即时更新功能，Capgo 可以无缝整合:
Capgo 与 GitHub 动作, 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 CI/CD 为产品工作流程在 Capgo CI/CD 中 Capgo 原生构建 为产品工作流程在 Capgo 原生构建 中 Capgo 集成 为产品工作流程在 Capgo 集成 中 CI/CD 集成 CI/CD 集成的实现细节 GitHub 动作集成 for the implementation detail in GitHub Actions Integration.
