Git 工作流模式
Git 版本控制、分支策略与协作开发的最佳实践。
何时启用
- 为新项目设置 Git 工作流
- 决定分支策略（GitFlow、主干开发、GitHub Flow）
- 编写提交信息和 PR 描述
- 解决合并冲突
- 管理发布和版本标签
- 让新团队成员熟悉 Git 实践
分支策略
GitHub Flow（简单，推荐大多数场景使用）
最适合持续部署以及中小型团队。
main (protected, always deployable)
│
├── feature/user-auth → PR → merge to main
├── feature/payment-flow → PR → merge to main
└── fix/login-bug → PR → merge to main
规则：
main始终可部署- 从
main创建功能分支 - 准备就绪后发起 Pull Request
- 审核通过且 CI 通过后，合并到
main - 合并后立即部署
主干开发（高速度团队）
最适合具备强大 CI/CD 和功能开关的团队。
main (主干)
│
├── 短期功能分支（最长1-2天）
├── 短期功能分支
└── 短期功能分支
规则：
- 所有人直接提交到
main或使用极短生命周期的分支 - 功能开关隐藏未完成的工作
- 合并前必须通过 CI
- 每天多次部署
GitFlow（复杂，基于发布周期）
适合计划性发布和企业级项目。
main (生产发布版本)
│
└── develop (集成分支)
│
├── feature/user-auth
├── feature/payment
│
├── release/1.0.0 → 合并到 main 和 develop
│
└── hotfix/critical → 合并到 main 和 develop
规则：
main仅包含生产就绪代码develop是集成分支- 功能分支从
develop创建，合并回develop - 发布分支从
develop创建，合并到main和develop - 热修复分支从
main创建，合并到main和develop
何时使用哪种策略
| 策略 | 团队规模 | 发布频率 | 最佳适用场景 | |-------…
