🚀 Git 分支使用规范全解(多人协作开发适用)
本文将为你梳理一套清晰、标准、适合企业/团队使用的 Git 分支管理策略,适用于前后端、边缘端、AI项目等多种场景。
🧩 为什么要规范分支管理?
- 防止多人协作混乱、冲突频发
- 清晰区分:开发中 / 待发布 / 已上线 的版本
- 快速定位问题来源:feature?hotfix?bugfix?
- 支持代码审查、回滚、自动部署等流程
🗂️ 分支结构总览
main # 🟢 生产环境分支,仅上线代码!
develop # 🟡 开发主干,合并所有功能与修复分支
feature/* # 🔵 新功能开发(每个功能一个分支)
bugfix/* # 🟣 小问题修复(非紧急)
release/* # 🟠 准备上线的发布版本
hotfix/* # 🔴 紧急修复生产Bug
📌 分支说明及使用规范
1️⃣ main
分支(主分支)
- 用途:唯一的线上生产环境代码
- 权限:受保护,禁止直接提交代码
- 来源:仅允许从
release/*
或hotfix/*
合并 - 自动化:一般绑定CI/CD自动部署脚本
2️⃣ develop
分支(开发主干)
- 用途:所有日常开发工作的集成中心
- 来源:
feature/*
、bugfix/*
合并至此 - 合并方式:推荐使用 Pull Request + 代码审查
3️⃣ feature/*
分支(功能分支)
- 命名示例:
feature/login-api
、feature/ai-detection
- 来源:从
develop
拉出 - 结束后:合并回
develop
,并删除本地/远程分支 - 命名规范:
feature/<功能简述>
4️⃣ bugfix/*
分支(非紧急问题修复)
- 命名示例:
bugfix/image-loading
- 来源:从
develop
拉出 - 用途:修复日常发现的小Bug
- 结束后:合并至
develop
5️⃣ release/*
分支(预发布分支)
- 命名示例:
release/v1.0.0
- 来源:从
develop
创建 - 用途:准备上线前的最终测试、优化
- 合并方向:最终合并至
main
和develop
- 注意事项:修复小Bug可直接改,重大改动新建
bugfix/*
6️⃣ hotfix/*
分支(紧急修复)
- 命名示例:
hotfix/login-crash
- 来源:从
main
拉出 - 用途:快速修复生产环境严重Bug
- 结束后:合并回
main
和develop
,发布热修复版本