分支策略与工作流

良好的分支策略是团队高效协作的基础。不同规模和场景的团队适合不同的工作流。

Git Flow

Git Flow 是由 Vincent Driessen 在 2010 年提出的经典工作流，适合有固定发布周期的项目。

分支结构

主分支（长期）：
├── main/master   - 生产环境代码，每次合并都打 Tag
└── develop       - 开发主线，集成所有功能

辅助分支（临时）：
├── feature/*     - 功能开发分支，从 develop 分出，合并回 develop
├── release/*     - 发布准备分支，从 develop 分出，合并到 main 和 develop
└── hotfix/*      - 紧急修复分支，从 main 分出，合并到 main 和 develop

工作流程

# 1. 开始新功能
git switch develop
git switch -c feature/user-auth

# 2. 功能开发完成，合并回 develop
git switch develop
git merge --no-ff feature/user-auth
git branch -d feature/user-auth

# 3. 准备发布，创建 release 分支
git switch develop
git switch -c release/1.2.0

# 4. release 分支只做 bug 修复
git commit -m "fix: 修复发布前发现的问题"

# 5. release 合并到 main 并打标签
git switch main
git merge --no-ff release/1.2.0
git tag -a v1.2.0 -m "Release version 1.2.0"

# 6. release 也要合并回 develop
git switch develop
git merge --no-ff release/1.2.0
git branch -d release/1.2.0

# 7. 紧急修复
git switch main
git switch -c hotfix/1.2.1-null-pointer
git commit -m "fix: 修复空指针异常"

# 8. hotfix 合并到 main 和 develop
git switch main
git merge --no-ff hotfix/1.2.1-null-pointer
git tag -a v1.2.1 -m "Hotfix 1.2.1"
git switch develop
git merge --no-ff hotfix/1.2.1-null-pointer
git branch -d hotfix/1.2.1-null-pointer

适用场景

✅ 适合：

• 有明确版本号的软件（如桌面应用、库/SDK）
• 需要维护多个版本
• 发布周期较长（数周一次）
• 团队规模较大，需要严格的权限控制

❌ 不适合：

• 持续部署的 Web 应用
• 小型团队
• 需要快速迭代的产品

优缺点

优点	缺点
清晰的版本管理	分支复杂，学习成本高
适合多版本并行维护	发布周期长，不适合 CD
职责分明	大量合并操作

GitHub Flow

GitHub Flow 是 GitHub 推广的简化工作流，只有一个长期分支（main），通过 Pull Request 进行代码审查。

分支结构

main           - 始终是可部署状态
feature/*      - 所有开发都在 feature 分支上

工作流程

# 1. 从 main 创建功能分支
git switch main
git pull
git switch -c feature/new-search

# 2. 持续开发和提交
git commit -m "feat: 添加搜索建议"
git push -u origin feature/new-search

# 3. 创建 Pull Request（在 GitHub 上操作）
# - 描述改动内容
# - 请求 Code Review
# - 关联相关 Issue

# 4. Code Review 后，合并到 main
# （在 GitHub 上点击 Merge 按钮）

# 5. 部署 main 到生产环境（自动或手动）

# 6. 删除功能分支
git push origin --delete feature/new-search
git branch -d feature/new-search

适用场景

✅ 适合：

• 持续部署（Continuous Deployment）的 Web 应用
• 小到中型团队
• 只维护一个版本（最新版）
• 需要快速迭代

❌ 不适合：

• 需要维护多个版本
• 发布前需要大量测试和准备

优缺点

优点	缺点
简单易懂	没有专门的发布流程
适合 CI/CD	不适合多版本维护
PR 流程内置 Code Review	main 不稳定时风险较高

GitLab Flow

GitLab Flow 在 GitHub Flow 的基础上增加了环境分支，更贴近实际部署需求。

环境分支模型

feature/* → main → staging → production

或者版本发布模型：
feature/* → main → release/1.x → release/2.x

工作流程

# 向 main 推送代码后，自动部署到 staging
# staging 测试通过后，手动合并到 production

git switch -c feature/new-feature
git commit -m "feat: ..."
# PR: feature → main
# 自动部署到 staging 环境
# 测试通过后：PR: main → production

适用场景

✅ 适合：

• 有多个部署环境（dev/staging/prod）
• 需要在发布到生产前进行额外测试
• 想要比 Git Flow 更简单，又比 GitHub Flow 更完整

Trunk Based Development（主干开发）

所有开发者都直接提交到主干（trunk/main），分支极短暂（1天内合并）。

工作流程

# 1. 直接在 main 上开发（小团队）
git switch main
git pull --rebase
# 修改代码
git commit -m "feat: 添加功能"
git push

# 2. 或者使用极短命的特性分支（1-2天）
git switch -c feature/quick-feature
# 快速开发完成
git commit -m "feat: 快速功能"
git switch main
git rebase feature/quick-feature  # 或 merge
git push

功能标志（Feature Flag/Toggle）：

主干开发需要配合功能开关，让未完成的功能可以安全合并：

if (featureFlags.isEnabled('new-search')) {
  // 新功能代码
} else {
  // 旧功能代码
}

适用场景

✅ 适合：

• 高度成熟的团队，有完整的测试覆盖
• 持续集成/持续部署（CI/CD）完善的团队
• Google、Facebook 等大型科技公司的内部实践

❌ 不适合：

• 测试覆盖不足的团队
• 没有 CI/CD 基础设施的项目
• 初级开发者为主的团队

优缺点

优点	缺点
集成冲突最小	需要高度纪律性
持续集成最彻底	必须有功能标志机制
历史最简洁	需要完整的自动化测试

如何选择适合团队的分支策略

决策树

团队规模？
├── 1-5人
│   └── GitHub Flow（简单高效）
├── 5-20人
│   ├── 有 CI/CD？
│   │   ├── 是 → GitHub Flow 或 GitLab Flow
│   │   └── 否 → Git Flow
│   └── 多版本维护？ → Git Flow
└── 20人以上
    ├── 单产品持续部署 → Trunk Based
    └── 多版本产品 → Git Flow 或 GitLab Flow

关键考量因素

因素	推荐工作流
持续部署	GitHub Flow / Trunk Based
多版本维护	Git Flow
严格发布流程	GitLab Flow
小团队快速迭代	GitHub Flow
大型成熟团队	Trunk Based

通用建议

1. 从简单开始：先从 GitHub Flow 开始，有需要时再引入复杂度
2. 根据实际调整：工作流是工具，适合团队的才是最好的
3. 统一执行：工作流的价值在于全团队一致遵守
4. 逐步改进：不要一次性引入过多规则

总结

工作流	分支数	复杂度	适合场景
GitHub Flow	少	低	持续部署 Web 应用
Git Flow	多	高	版本发布型软件
GitLab Flow	中	中	多环境部署
Trunk Based	极少	低（但要求高）	成熟团队持续交付

没有完美的工作流，只有适合当前团队和项目的工作流。选择后坚持执行，并随着团队成长不断优化。