Git代码提交与分支管理规范

一、分支管理规范

1. 分支类型

• main/master
  • 主分支，代码始终处于 生产环境可用状态。
  • 禁止直接提交代码，只能通过合并其他分支更新。
• develop
  • 开发主分支，用于集成最新功能，代表下个版本的代码。
  • 功能分支需合并至此分支。
• feature/[功能名]
  • 功能开发分支，基于 develop 创建，完成开发后合并回 develop。
  • 命名示例：feature/user-login
• release/[版本号]
  • 预发布分支，用于版本测试和修复，基于 develop 创建，完成后合并到 main 和 develop。
  • 命名示例：release/v1.2.0
• hotfix/[问题描述]
  • 紧急修复分支，基于 main 创建，修复后合并到 main 和 develop。
  • 命名示例：hotfix/payment-bug

2. 分支操作规则

• 创建分支
  • 明确分支用途，避免混杂多个功能。
  • 基于正确的父分支创建（如 develop 或 main）。
• 删除分支
  • 合并完成后及时删除废弃分支（如已合并的 feature 或 hotfix）。
• 分支同步
  • 定期从主分支（develop/main）拉取最新代码，避免冲突。

---

二、代码提交规范

1. Commit Message 格式

建议使用 Conventional Commits 规范，格式如下：

<类型>[可选范围]: <描述>

[可选正文]

[可选脚注]

• 常用类型：
  • feat: 新功能
  • fix: Bug修复
  • docs: 文档变更
  • style: 代码格式调整（不影响逻辑）
  • refactor: 代码重构（非功能变更）
  • test: 测试代码
  • chore: 构建/依赖更新等杂项
• 示例：

  feat(user): add login API
  fix(payment): handle timeout error
  docs: update README.md
  

2. 提交规则

• 原子性提交
  每次提交只解决一个明确的问题，避免混杂多个修改。
• 描述清晰
  使用简洁的英文或团队约定语言，避免模糊描述（如“修复问题”）。
• 关联 Issue
  在正文或脚注中关联任务编号（如 Closes #123）。

---

三、代码合并规范

1. Pull Request (PR) / Merge Request (MR)

   • 所有分支合并需通过 PR/MR，禁止直接推送主分支。
   • PR 需关联具体任务（如 Jira Issue ID）。
   • 必须通过 代码审查 和 CI 测试 后方可合并。

2. 冲突解决

   • 合并前在本地解决冲突，确保目标分支（如 develop）代码完整。

---

四、辅助工具推荐

1. Git Hooks
   • 使用 commit-msg 钩子检查提交信息格式。
   • 使用 pre-commit 钩子自动格式化代码（如 ESLint、Prettier）。
2. CI/CD 集成
   • 在流水线中自动检查分支规范、测试覆盖率等。
3. 可视化工具
   • 使用 gitk、SourceTree 或 Git Graph 插件管理分支。

---

五、紧急情况处理

• Hotfix 流程：
  1. 从 main 切出 hotfix 分支。
  2. 修复后合并到 main 和 develop。
  3. 打新版本标签（如 v1.2.1）。

---

六、权限管理

• 保护主分支（main/develop），仅允许通过 PR/MR 合并。
• 限制直接推送权限，避免误操作。