Git 分支管理规范
1. 文档目的
为统一团队代码分支管理标准，规范分支命名、创建、合并、删除等操作，提升协作效率，降低代码冲突与上线风险，特制定本规范。
2. 适用范围
本规范适用于团队所有使用 Git 进行代码管理的项目及所有开发人员。
3. 分支类型与命名规范
3.1 长期分支
1. main / master
· 用途：生产环境代码，随时可部署上线
· 规则：禁止直接提交，仅允许通过 MR/PR 合并
1. develop
· 用途：开发主分支，日常开发集成分支
· 规则：所有功能、bug 修复最终合并到此
3.2 临时分支
1. 功能分支
· 命名：feature/需求ID-功能描述
· 示例：feature/PROJ-123-user-login
· 来源：develop
· 合并目标：develop
1. 开发环境 bug 修复分支
· 命名：bugfix/问题ID-问题描述
· 示例：bugfix/PROJ-456-login-fail
· 来源：develop
· 合并目标：develop
1. 生产紧急修复分支
· 命名：hotfix/问题ID-问题描述
· 示例：hotfix/PROJ-789-pay-crash
· 来源：main
· 合并目标：main、develop
1. 发布分支
· 命名：release/版本号
· 示例：release/v1.2.0
· 来源：develop
· 合并目标：main、develop
4. 分支操作规范
4.1 分支创建
· 创建新分支前必须拉取最新基准分支代码
· 分支名统一小写，使用 - 分隔，不使用中文、空格、特殊符号
4.2 代码提交规范
提交信息格式：
类型(模块/ID): 描述
类型说明：
· feat：新功能
· fix：修复 bug
· docs：文档修改
· style：格式调整
· refactor：重构
· test：测试相关
· chore：构建 / 工具类修改
4.3 分支合并
· 禁止直接 push 到 main、develop
· 必须通过 MR/PR 提交合并
· 合并前需通过：代码评审 + 自动化构建 / 测试
· 功能分支推荐 squash merge
· 发布 / 热修复分支保留 merge 记录
4.4 分支删除
· 临时分支合并完成后，立即删除本地与远程分支
· 定期清理无效、过期、已合并分支
5. 版本发布流程
1. 从 develop 创建 release 分支
2. 在 release 分支仅修复发布阻塞 bug，不新增功能
3. 测试通过后合并到 main 并打 Tag
4. 将 release 分支合并回 develop
5. 版本标签格式：v主版本.次版本.修订号，如 v1.0.0、v1.2.1
6. 生产紧急修复流程（hotfix）
1. 从 main 新建 hotfix 分支
2. 修复问题并自测
3. 合并到 main，打补丁版本 Tag
4. 同步合并回 develop
5. 删除 hotfix 分支
7. 冲突处理
· 优先在本地解决冲突
· 解决后必须重新自测
· 禁止强行覆盖他人代码
8. 规范要求与落地
1. 仓库开启 main/develop 分支保护
2. 强制 MR/PR 审批机制
3. 接入 CI/CD 自动检查
4. 团队成员必须遵守本规范
5. 定期 review 分支使用情况，清理无效分支