Git Flow vs Trunk-Based Development 对比

结构化分支策略——main、develop、feature、release、hotfix

VS
Trunk-Based Development

单一主分支,频繁提交,通过feature flag实现安全部署

8 分钟阅读Araçlar

评分对比

图表加载中…

详细评分

详细评分: Git Flow Trunk-Based Development ——按类别打分,满分 10 分
分类Git FlowTrunk-Based Development
性能
6/10
9/10
学习难易度
5/10
7/10
生态系统
8/10
9/10
社区
8/10
9/10
就业市场
8/10
9/10
面向未来
5/10
10/10

优缺点

Git Flow

优点

  • 明确的发布周期——清楚何时发布什么内容
  • 支持并行开发——多个feature可同时推进
  • hotfix机制——生产环境紧急修复流程清晰
  • 为大型团队的协调提供结构支持
  • 与语义化版本管理配合良好
  • 与移动应用发布周期契合(App Store审核流程)

缺点

  • 复杂——需要学习5种分支类型和合并策略
  • 长生命周期分支容易造成合并冲突噩梦
  • 迭代速度慢——develop → release → main的流程增加延迟
  • 与CI/CD集成较为复杂
  • feature分支可能持续数周——集成地狱
  • 对小团队来说负担过重

最适合

有计划性发布周期的产品(移动应用、固件)大型分布式团队App Store / Play Store发布管理需要支持并行版本的产品需要合规和审计的企业软件

Trunk-Based Development

优点

  • 简洁——只有一条main/trunk分支,分支生命周期很短
  • 持续集成——每个人每天多次推送到trunk
  • 最小化合并冲突——分支存活时间最长不超过1-2天
  • 快速反馈循环——CI能立即运行
  • 通过feature flag实现部署与发布解耦——安全的暗启动
  • Google、Facebook、Netflix等公司采用的策略
  • 与DevOps和CI/CD天然契合

缺点

  • feature flag管理需要额外的基础设施
  • 每个人每天都必须推送到trunk——需要严格的纪律
  • 对有计划性发布周期的场景不太适用
  • 未完成的功能会留存在trunk中——flag管理至关重要
  • 在没有强大CI/CD基础设施和测试覆盖率的团队中风险较高
  • 在移动应用中,由于App Store审核流程,难以完全落实

最适合

Web服务和SaaS产品中小型高频迭代团队拥有强大CI/CD流水线的组织以持续部署(continuous deployment)为目标的团队已具备feature flag基础设施的产品

代码对比

Git Flow
# Git Flow - 完整工作流示例
# 初始设置
git flow init -d
# 分支:main、develop、feature/、release/、hotfix/

# 开发新功能
git flow feature start user-profile-redesign
# → 创建了 feature/user-profile-redesign 分支

# 开发过程
git add src/views/ProfileView.swift
git commit -m "feat(profile): redesign user profile card"
git add src/viewmodels/ProfileViewModel.swift
git commit -m "feat(profile): add avatar lazy loading"

# 功能完成——合并到develop
git flow feature finish user-profile-redesign
# → feature分支被删除,已合并到develop

# 发布准备
git flow release start 2.4.0
# → 创建了 release/2.4.0 分支

# release分支上只做bug修复!
git commit -m "fix: avatar cache invalidation on logout"
git commit -m "chore: bump version to 2.4.0"

# 发布完成
git flow release finish 2.4.0
# → 合并到main,创建标签(v2.4.0),回合并到develop

# 发现生产环境问题
git flow hotfix start fix-crash-on-launch
git commit -m "fix: nil pointer in AppDelegate startup"
git flow hotfix finish fix-crash-on-launch
# → 合并到main和develop,打上v2.4.1标签
Trunk-Based Development
# Trunk-Based Development - 日常工作流

# 每天早晨:从最新代码开始
git pull origin main

# 短生命周期feature分支(最多1-2天!)
git checkout -b feat/quick-login-improvement

# 小而原子化的提交
git add src/views/LoginView.swift
git commit -m "feat: add biometric login button"

git add tests/LoginTests.swift
git commit -m "test: biometric auth unit tests"

# 立即合并到trunk(即使未完成,也用feature flag隐藏!)
git checkout main
git pull origin main
git merge feat/quick-login-improvement
git push origin main
git branch -d feat/quick-login-improvement

# 用feature flag隐藏未完成的功能(Swift)
# FeatureFlags.swift
enum FeatureFlag: String {
    case newLoginUI = "new_login_ui"
    case profileV2 = "profile_v2"
    case darkModeV3 = "dark_mode_v3"
}

class FeatureFlagService {
    static func isEnabled(_ flag: FeatureFlag) -> Bool {
        // 从远程配置或本地覆盖中读取
        return RemoteConfig.shared.bool(forKey: flag.rawValue)
    }
}

// 在View中使用
if FeatureFlagService.isEnabled(.newLoginUI) {
    NewLoginView()
} else {
    LegacyLoginView()
}

# CI/CD流水线(GitHub Actions)
# .github/workflows/ci.yml:
# on: push (branches: [main])
# → lint → test → build → deploy staging → smoke test → deploy production

结论

对于Web服务和SaaS产品而言,Trunk-Based Development是现代标准——与CI/CD完美契合,迭代速度快。对于iOS应用,轻量版的Git Flow(仅main + feature分支)较为实用:App Store审核流程和版本发布周期更适合这种结构。GitHub Flow(main + 短生命周期的feature分支)是一个不错的折中方案。

获取免费咨询
常见问题

常见问题

GitHub Flow是简化版本:只有main和feature分支,没有release分支和develop分支。对中小型团队来说是理想的折中选择。

相关博客文章

查看全部文章

相关项目

查看全部项目
全部对比