代码版本管理工作流程

1. 分支策略

• 主分支 (master 或 main)

  • 始终保持稳定，仅用于发布或已测试的代码。
  • 禁止直接在主分支上提交代码，所有改动需通过 Pull Request (PR) 或 Merge Request (MR) 合并。

• 开发分支 (develop)

  • 用于集成团队成员的日常开发工作。
  • 团队成员从此分支拉取最新代码并创建功能分支。

• 功能分支 (feature/xxx)

  • 每个功能或任务创建独立分支，如 feature/login-page。
  • 基于 develop 分支创建，完成后通过 PR 合并回 develop。

• 修复分支 (bugfix/xxx或hotfix/xxx)

  • 按照 Bug 紧急程度划分 bugfix开头的是不紧急 Bug hotfix开头的是紧急 Bug。
  • 修复紧急 Bug 时直接从 main 拉取，修复完成后合并回 main 和 develop。
  • 修复不紧急 Bug 时从 develop 分支拉取修复完成后通过下个小版本修复

• 发布分支 (release/xxx)

  • 发布版本前创建，如 release/v0.0.1。
  • 用于最终测试和文档修改，完成后合并到 main 和 develop。

2. 协作流程

1. 拉取最新代码

   • 每日开始工作前，拉取 develop 分支最新代码：

     git pull origin develop

2. 创建功能分支

   • 根据任务在 develop 分支上创建新的功能分支：

     git checkout -b feature/feature-name develop

3. 开发并提交代码

   • 开发完成后提交到功能分支：

     git add .
     git commit -m "feature: 描述功能或修复的内容"
     git push origin feature/feature-name

4. 代码评审 (Code Review)

   • 提交 PR/MR 并邀请团队成员进行代码评审。
   • 评审通过后合并到 develop。

5. 测试

   • 在 develop 分支集成所有功能后进行测试。

6. 版本发布

   • 创建 release 分支进行最终测试和小改动。

   • 修改项目中pom.xml文件中的 reversion属性 更新版本号

   • 确保测试完成后合并到 master，并创建版本标签：

     git tag -a v0.0.1 -m "Release v0.0.1"
     git push origin v0.0.1

7. 修复紧急 Bug

   • 修复时从 master 创建 hotfix 分支，完成后同步回 master 和 develop。

3. 权限管理

• 主分支保护：启用分支保护规则，限制直接提交：
  • 需通过 PR/MR 合并。
  • 需要至少 1-2 名团队成员审批。
• 开发分支同步：每天或每周定期同步进度，减少冲突。

4. 定期检查

• 每周短会确认功能进度与阻碍。
• 及时清理已完成或废弃的分支，保持代码库整洁。