workflow
Git 工作流（Git Workflow）总结对比表
| 工作流 | 核心分支 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|---|
| GitHub Flow | main + 短命特性分支 | Web 应用、SaaS、高频交付 | 简单、快速迭代 | 不适合多版本维护 |
| Git Flow | main/develop + feature/release/hotfix | 传统软件、版本发布项目 | 版本管理清晰 | 分支复杂，流程繁琐 |
| Trunk-Based | 只有 main（或极短命分支） | 成熟 DevOps 团队、CI/CD 高速交付 | 部署极快、减少合并冲突 | 依赖强测试和团队纪律 |
| GitLab Flow | main → staging → production | 多环境部署（如预发布和生产） | 直观匹配 DevOps 流程 | 比 GitHub Flow 稍复杂 |
| Forking Flow | 每个开发者 Fork 主仓库 + PR | 开源协作项目 | 安全可控，适合大规模协作 | 依赖维护者审核 |
| OneFlow | main + develop（简化版 Git Flow） | 需要版本管理但不想太复杂 | 比 Git Flow 更轻量 | 仍比 GitHub Flow 复杂 |
如何选择？
- 高频交付的 Web 项目 → GitHub Flow 或 Trunk-Based
- 需要版本发布的软件 → Git Flow 或 OneFlow
- 多环境（Staging/Prod） → GitLab Flow
- 开源协作 → Forking Flow
核心原则：
- 保持简单：分支越多，维护成本越高。
- 匹配团队习惯：没有“最好”，只有“最适合”。
- 自动化测试/CI 是关键，尤其是 Trunk-Based 和 GitHub Flow。