Trunk-Based Development

Trunk-Based Development（主干开发）是最简洁的工作流，开发者直接在主干上开发或使用短生命周期分支。

什么是 Trunk-Based Development

开发者主要在 trunk（主干）上工作：

• 直接提交到主干
• 或使用极短的生命周期分支
• 频繁集成，避免长期分支

分支策略

方式1：直接在主干开发
trunk ──●──●──●──●──●──●──→
       开发者A、B、C都在 trunk 上提交

方式2：短生命周期分支
trunk ───●────●────●────●──→
        │     │     │
短分支   ●────┘     ●────┘
        <1天       <1天

核心原则

工作流程

直接提交到主干

# 更新主干
git checkout trunk
git pull origin trunk

# 开发并提交
git add .
git commit -m "feat: 小功能"

# 推送（CI 自动验证）
git push origin trunk

# 如有问题立即回滚
git revert HEAD
git push origin trunk

短生命周期分支

# 创建短分支（预期 < 1天）
git checkout trunk
git checkout -b short-task

# 快速完成
git add .
git commit -m "feat: 快速任务"

# 合入主干
git checkout trunk
git merge short-task

# 立即删除
git branch -d short-task

与其他工作流对比

适用场景

成功要素

强大的自动化测试

# CI 必须快速可靠
tests:
  - unit tests（必须）
  - integration tests（推荐）
  - smoke tests（推荐）

# 测试覆盖率要求
coverage: > 80%

快速回滚能力

# 有问题立即回滚
# 回滚时间 < 5 分钟

git revert HEAD
git push origin trunk

# 或自动回滚
# CI 失败自动回滚

特性开关

// 使用特性开关隐藏未完成功能
if config.IsEnabled("new-feature") {
    return newFeature()
}
return oldFeature()

特性开关（Feature Flags）

# 未完成功能提交到 trunk
# 通过开关隐藏，不影响生产

# 开发完成后打开开关
# 逐步开放给用户

代码审查

Trunk-Based 审核方式：

方式1：提交后审核（Post-commit review）
提交 → Push → 自动审核 → 回滚（如有问题）

方式2：提交前审核（Pre-commit review）
提交 → 自动检查 → 同步审核 → Push

Trunk-Based 需要高成熟度团队和强大自动化，不适合初学者。

要点总结

1. 开发者主要在主干上工作
2. 分支生命周期极短（< 1-2 天）
3. 需要强大的自动化测试
4. 使用特性开关隐藏未完成功能
5. 有问题立即回滚，不阻塞主干