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