一、Git 分支管理规范（业界主流实践）

首先要建立清晰的分支模型，推荐使用 Git Flow 简化版（兼顾规范与易用性），适合大多数中小团队：

1. 分支命名与用途

2. 分支操作核心命令（实战）

# 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-login

2. 发起 PR/MR 并配置

1. 目标分支选择 develop（功能分支）或 main（热修复分支）；
2. 填写清晰的 PR 描述：
   • 需求背景：解决了什么问题；
   • 核心改动：修改了哪些文件 / 逻辑；
   • 测试要点：需要重点验证的场景；
3. 指定至少 1 名 Code Review 人员；
4. 开启 CI/CD 检查（自动化测试、代码规范）。

3. Code Review 流程规范

（1）Review 人员职责

• 检查代码逻辑：是否有 bug、边界条件是否覆盖；
• 检查代码规范：命名、注释、格式是否符合团队要求；
• 检查性能 / 安全：是否有性能隐患、安全漏洞；
• 提出明确建议：避免模糊评价（如 “这里不太好”），需说明 “为什么不好”+“建议怎么改”。

（2）Review 反馈处理

• 若 Review 提出问题：修改代码后重新推送（git push），PR 会自动更新；
• 若有争议：通过团队沟通（如会议）达成一致，避免无意义的文字争论；
• 所有 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

三、关键保障措施

1. 分支保护：在 Git 平台（GitHub/GitLab）设置 main/develop 分支保护：
   • 禁止直接推送；
   • 必须通过 PR/MR 且 Review 批准后才能合并；
   • 必须通过 CI/CD 检查。
2. 提交信息规范：使用 Conventional Commits 规范（如 feat: 新增登录功能、fix: 修复登录验证码过期问题），便于自动化生成版本日志。
3. 定期清理分支：每周清理无效分支（如已合并的功能分支、过时的测试分支）。
4. 文档同步：将分支规范、PR 流程、Review 标准写入团队开发文档，新人入职后先学习。

总结

1. 分支管理：采用简化版 Git Flow，明确分支命名和用途，禁止直接操作主分支；
2. 代码合并：通过 PR/MR 驱动，必须完成 Code Review 和 CI 检查才能合并；
3. 流程规范：分支保护 + 提交规范 + Review 标准，三者结合保障团队协作的规范性。