1 分支管理策略
在团队协作中，清晰的分支管理策略至关重要。我推荐使用 main + develop/版本号 + release/版本号 的分支管理方式。这种方式不仅适合中小型团队，对于大型团队同样适用——大型团队可以在此基础上按模块或子系统并行维护多个 develop 分支，各自独立开发、互不干扰，最终统一汇入对应的 release 分支发布。
2 分支说明
2.1 main 分支
- 主分支，始终保持稳定
- 只接受来自 release 分支的合并
- 代表生产环境的代码
2.2 develop/版本号 分支
- 开发分支，用于日常开发
- 命名格式：
develop/1.0.0 - 从 main 分支创建
- 开发完成并发布后需要删除
2.3 release/版本号 分支
- 发布分支，代表已发布的版本
- 命名格式：
release/1.0.0 - 从对应的 develop 分支创建
- 合并到 main 后长期保留，便于追溯
3 工作流程
- 开始新版本开发
git checkout main
git pull
git checkout -b develop/1.0.0
- 日常开发
git checkout develop/1.0.0
# 进行开发工作
git add .
git commit -m "feat: 添加新功能"
git push origin develop/1.0.0
- 准备发布
git checkout develop/1.0.0
git checkout -b release/1.0.0
git push origin release/1.0.0
- 合并到 main
git checkout main
git merge release/1.0.0
git tag 1.0.0
git push origin main --tags
- 删除 develop 分支
# 删除本地分支
git branch -d develop/1.0.0
# 删除远程分支
git push origin --delete develop/1.0.0
4 优势
- 清晰的版本管理：通过分支名称即可了解版本状态
- 历史可追溯：release 分支长期保留，便于回溯
- 分支整洁：develop 分支发布后删除，避免分支堆积
- 流程简单：相比 Git Flow 更轻量，中小型团队可直接使用
- 横向扩展：大型团队可并行维护多个 develop 分支（如
develop/1.0.0-moduleA、develop/1.0.0-moduleB），按模块独立开发，发布时统一合入 release 分支
5 注意事项
- develop 分支仅用于开发阶段，发布后必须删除（大型团队中各模块的 develop 分支同样需要在发布后清理）
- release 分支创建后不应再进行功能开发，仅做 bug 修复
- 所有 release 分支都要合并到 main 并打上对应的 tag
- 版本号建议遵循语义化版本规范（Semantic Versioning）