选择 Git Flow 或 Trunk-Based 开发（TBD）会显著影响您的 CI/CD 流程。以下是快速概述： Git Flow 和 Trunk-Based 开发（TBD）
- Git Flow: 最适合结构化、版本控制的环境。它使用多个分支，如
main,develop,feature,release,和hotfix。适合大型团队、缓慢的发布周期和严格的QA流程。 - Trunk-Based Development: 集中在一个主要分支上，短暂的特性分支。适合小型团队、快速发布和强大的自动化测试。
快速比较：
| 方面 | Git Flow | Trunk-Based Development |
|---|---|---|
| 分支复杂度 | 多个长期分支 | 单个分支，短暂的分支 |
| 发布频率 | 预定发布 | 持续部署 |
| 团队规模 | 大型团队 | 小型到中型团队 |
| 测试 | 周期末测试 | 自动化测试 |
| 部署风险 | 使用分阶段发布时降低 | 频繁更新时风险增加 |
| 回滚 | 速度较慢 | 速度较快 |
主要 takeaway: 使用 Git Flow 进行结构化的、速度较慢的工作流程，TBD 为速度和灵活性。两者都需要坚实的 CI/CD pipeline 才能成功。
29 - GitFlow 与 Trunk-Based Development: 管理 …
Git Flow 工作流程基础
Git Flow 使用五种分支类型来组织开发： 主分支, 开发, 功能, 发布, 和 修复. 这种结构有助于有效地管理发布和并行开发。
Git Flow Branch 结构
| Branch 类型 | 目的 | 合并目标 |
|---|---|---|
| 主 | 保存生产就绪的 code | N/A |
| 开发 | 集成特性，作为特性分支的基础 | N/A |
| 特性 | 用于构建单个特性，基于开发分支创建 | 开发 |
| 发布 | 准备最终测试和版本化，基于开发分支创建 | 主分支 & 开发分支 |
| 热修复 | 快速修复生产问题，基于主分支创建 | 主 & 开发 |
Git Flow 优势
- 允许同时开发多个功能而不导致冲突。
- 发布分支为最终测试和版本准备提供了专门的空间，保持 develop branch
- 开放进行持续工作。 Hotfix
branch
- 使快速解决生产问题变得容易而不会中断其他开发任务。Git Flow 缺点
- 分支管理复杂性：管理多个活跃分支会使合并更具挑战性。: The formal release process may slow down deployments compared to simpler workflows.
- Increased Maintenance: 每个 branch 都需要自己的 pipeline 配置，这会增加维护工作量。
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
在典型的 TBD 工作流中，你会遇到这些 branch 类型：
| Branch Type | Purpose | Lifespan |
|---|---|---|
| Main/Trunk | 中央分支，生产就绪的code | 永久 |
| 特性分支 | 用于个别变更的临时分支 | 短暂 |
| 发布分支 | 用于发布前的最后调整 | 临时 |
开发人员经常将小的、增量的变更合并到主分支中 - 经常在一天内进行多次。这有助于持续测试并快速解决冲突。
干线开发的好处
TBD 为 CI/CD 和 DevOps 工作的团队带来了几个优势：
- 少量的合并冲突: Regular merges keep conflicts manageable.
- 更快的反馈: 自动化构建在每次合并时运行，尽早捕获错误。
- 更简单的管道: 单一分支减少了 CI/CD 设置的复杂性。
- 更好的团队协作: 共享的主干确保每个人都保持一致。
这种结构创建了一个流线化的工作流程，为下一节与 Git Flow 进行比较做好准备。
主干限制
虽然 TBD 有其优势，但它也带来了团队需要解决的问题：
| 挑战 | 影响 | 如何解决冲突 |
|---|---|---|
| Code 稳定性 | 可能的破坏性更改影响主线 | 使用强大的自动化测试 |
| 团队协调 | 重叠的工作可能会导致中断 | 依赖于特性标志和频繁的小型提交 |
| 学习曲线 | 从长期分支过渡 | 提供培训并逐渐过渡 |
| 规模问题 | 频繁的合并可能会淹没大型团队 | 严格执行 code 的审查 |
成功采用 TBD 需要团队内部的自动化测试和开放的沟通
Git Flow 与 Trunk-Based 的直接比较
Git Flow 和 Trunk-Based 开发在关键方面的对比
特性比较表格
| 方面 | Git Flow | Trunk-Based 开发 |
|---|---|---|
| Branch 复杂度 | 多个长期分支 | 单个主分支，短期分支 |
| 发布频率 | 预定发布 | 持续部署 |
| 团队大小 | 适合较大的团队 | 更适合小型团队 |
| Code 代码审查流程 | 分支合并时进行正式审查 | 持续审查小型、频繁的代码变更 |
| 测试要求 | 关注周期末测试 | 依赖自动化测试 |
| 学习曲线 | 由于多个 branch 的关系，更加复杂 | 虽然流程更简单，但需要强大的测试 |
| 部署风险 | 通过分阶段发布降低风险 | 频繁更新会带来更高的风险 |
| 恢复时间 | 回滚过程较慢 | 更快的恢复能力 |
使用每种工作流程的时机
Git Flow 适合企业级项目，需要结构化的版本发布。它适合管理多个支持版本的团队，以及具有正式QA或合规需求的项目。
分支式开发 适合优先考虑速度和灵活性的团队和项目，例如：
- SaaS 平台需要快速更新
- 拥有强大 CI/CD pipeline 的团队
- 依赖可靠自动化测试的项目
- 持续部署工作流或频繁发布
- 需要定期更新的移动应用项目
有些团队甚至结合了这两种方法：使用 Trunk-Based Development 为核心服务和 Git Flow 为具有正式发布跟踪的项目
下一步：如何设置 CI/CD pipeline 以便采用任意一种方法
CI/CD Pipeline 设置
Git Flow CI/CD 设置
- 开发分支 pipeline：运行单元测试、集成测试、code 质量检查、构建验证和部署到开发环境。
- 发布 Branch Pipeline: 执行完整的测试套件、安全扫描、构建发布候选版本并部署到预发布环境。
- 主 Branch Pipeline: 进行验证测试、处理版本号、创建生产构建、部署到生产环境并标记发布。
Trunk-Based CI/CD Setup
- : 特别关注快速单元测试、__CAPGO_KEEP_0__ 风格检查、构建验证和预览环境部署。: Focuses on quick unit tests, code style checks, build verification, and deployment to a preview environment.
- : 覆盖全面自动化测试、安全扫描、生产构建创建、渐进式部署和自动回滚功能。__CAPGO_KEEP_0__
Capgo __CAPGO_KEEP_0__ 实时更新仪表板界面
为了在 CI/CD 设置中添加实时的在线更新，Capgo 可以无缝整合:
Capgo 与 GitHub Actions, GitLab CI, 和 Jenkins 来启用实时更新、分阶段发布和即时回滚功能，适用于 Git Flow 和 Trunk-Based 管道。它满足 Apple 和 Google 的要求，同时支持云和自主部署 [1].
概要和建议
根据您的团队大小和 CI/CD 成熟度水平选择您的工作流程，以下表格提供参考:
| 场景 | Git Flow | Trunk-Based |
|---|---|---|
| 团队规模 | 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 动作集成 为 GitHub 动作集成的实现细节
