一、Git 分支管理规范业界主流实践首先要建立清晰的分支模型推荐使用Git Flow 简化版兼顾规范与易用性适合大多数中小团队1. 分支命名与用途分支类型命名规范用途主分支main/master生产环境代码始终保持可部署状态开发分支develop集成分支日常开发基于此分支功能分支feature/xxx开发新功能如feature/user-login修复分支bugfix/xxx修复开发环境问题如bugfix/login-validation热修复分支hotfix/xxx修复生产环境紧急问题如hotfix/prod-500-error发布分支release/vx.x.x预发布测试如release/v1.2.02. 分支操作核心命令实战# 1. 基于 develop 创建功能分支 git checkout develop git pull origin develop # 先拉取最新代码 git checkout -b feature/user-login # 2. 开发过程中定期同步 develop 代码避免冲突 git checkout develop git pull git checkout feature/user-login git merge develop # 合并最新 develop 到功能分支 # 3. 功能完成后推送分支到远程 git add . git commit -m feat: 完成用户登录功能开发 # 遵循Conventional Commits规范 git push origin feature/user-login二、代码合并流程PR/MR 驱动代码合并必须通过Pull Request (GitHub/Gitee)或Merge Request (GitLab)禁止直接推送到main/develop分支流程如下1. 发起 PR/MR 前准备# 1. 确保本地分支是最新的再次同步 develop git pull origin develop # 2. 自检代码格式化、lint 检查 npm run lint # 前端示例后端可对应使用 go fmt、pylint 等 git add . git commit --amend # 修复 lint 问题后合并到最后一次提交 # 3. 推送最终代码 git push origin feature/user-login2. 发起 PR/MR 并配置目标分支选择develop功能分支或main热修复分支填写清晰的 PR 描述需求背景解决了什么问题核心改动修改了哪些文件 / 逻辑测试要点需要重点验证的场景指定至少 1 名 Code Review 人员开启 CI/CD 检查自动化测试、代码规范。3. Code Review 流程规范1Review 人员职责检查代码逻辑是否有 bug、边界条件是否覆盖检查代码规范命名、注释、格式是否符合团队要求检查性能 / 安全是否有性能隐患、安全漏洞提出明确建议避免模糊评价如 “这里不太好”需说明 “为什么不好”“建议怎么改”。2Review 反馈处理若 Review 提出问题修改代码后重新推送git pushPR 会自动更新若有争议通过团队沟通如会议达成一致避免无意义的文字争论所有 Review 人员批准后才能合并代码。4. 代码合并操作# 方式 1通过平台界面合并推荐保留 PR 记录 # 方式 2本地合并仅应急使用 git checkout develop git merge --no-ff feature/user-login # --no-ff 保留分支历史 git push origin develop # 合并后删除本地/远程功能分支 git branch -d feature/user-login git push origin --delete feature/user-login三、关键保障措施分支保护在 Git 平台GitHub/GitLab设置main/develop分支保护禁止直接推送必须通过 PR/MR 且 Review 批准后才能合并必须通过 CI/CD 检查。提交信息规范使用 Conventional Commits 规范如feat: 新增登录功能、fix: 修复登录验证码过期问题便于自动化生成版本日志。定期清理分支每周清理无效分支如已合并的功能分支、过时的测试分支。文档同步将分支规范、PR 流程、Review 标准写入团队开发文档新人入职后先学习。总结分支管理采用简化版 Git Flow明确分支命名和用途禁止直接操作主分支代码合并通过 PR/MR 驱动必须完成 Code Review 和 CI 检查才能合并流程规范分支保护 提交规范 Review 标准三者结合保障团队协作的规范性。