FCAT

Appearance

Git 项目管理规范是团队协作中非常重要的一环，它能够确保代码库的整洁、提交历史的清晰以及开发流程的高效。以下是一个常见的 Git 项目管理规范，涵盖分支管理、提交消息、代码合并和版本发布等方面。

1. 分支管理规范 ​

1.1 分支命名 ​

  • 主分支：
    • main 或 master：用于存放稳定的、可发布的代码。
    • develop：用于日常开发，集成分支。
  • 功能分支：
    • feature/<功能名称>：用于开发新功能，例如 feature/user-auth。
  • 修复分支：
    • fix/<问题描述>：用于修复 bug，例如 fix/login-error。
  • 发布分支：
    • release/<版本号>：用于准备发布版本，例如 release/v1.2.0。
  • 热修复分支：
    • hotfix/<问题描述>：用于紧急修复生产环境的问题，例如 hotfix/critical-bug。

1.2 分支生命周期 ​

  • 功能分支：
    • 从 develop 分支创建。
    • 开发完成后，合并到 develop 分支。
    • 合并后删除该分支。
  • 修复分支：
    • 从 develop 分支创建。
    • 修复完成后，合并到 develop 分支。
    • 合并后删除该分支。
  • 发布分支：
    • 从 develop 分支创建。
    • 测试完成后，合并到 main 和 develop 分支。
    • 合并后删除该分支。
  • 热修复分支：
    • 从 main 分支创建。
    • 修复完成后，合并到 main 和 develop 分支。
    • 合并后删除该分支。

2. 提交消息规范 ​

2.1 提交消息格式 ​

遵循 Conventional Commits 规范，提交消息格式如下：

<类型>(<范围>): <描述>
<类型>(<范围>): <描述>
  • 类型：
    • feat：新功能。
    • fix：修复 bug。
    • docs：文档更新。
    • style：代码格式化（不影响功能）。
    • refactor：代码重构（既不是新功能，也不是修复 bug）。
    • test：测试代码。
    • chore：构建或辅助工具的变动。
  • 范围（可选）：说明提交的影响范围，例如模块或文件。
  • 描述：简洁明了地描述提交内容。

示例：

feat(user): 添加用户登录功能
fix(auth): 修复登录失败的问题
docs(readme): 更新项目文档
feat(user): 添加用户登录功能
fix(auth): 修复登录失败的问题
docs(readme): 更新项目文档

2.2 提交消息注意事项 ​

  • 使用英文或团队统一的语言。
  • 描述尽量简洁，不超过 50 个字符。
  • 如果需要详细说明，可以在提交消息正文中添加。

3. 代码合并规范 ​

3.1 合并方式 ​

  • Merge Commit：保留完整的提交历史，适合功能分支合并。
  • Rebase：将分支提交历史整理为线性，适合小型分支。
  • Squash and Merge：将多个提交合并为一个，适合清理提交历史。

3.2 合并流程 ​

  1. 在合并前，确保代码通过代码审查（Code Review）。
  2. 在合并前，运行测试用例，确保代码质量。
  3. 合并后，删除已合并的分支。

4. 版本发布规范 ​

4.1 版本号规范 ​

遵循 Semantic Versioning（语义化版本）：

  • 主版本号（Major）：不兼容的 API 变更。
  • 次版本号（Minor）：向下兼容的功能新增。
  • 修订号（Patch）：向下兼容的问题修复。

示例：v1.2.3

4.2 发布流程 ​

  1. 从 develop 分支创建 release/<版本号> 分支。
  2. 在发布分支上进行测试和修复。
  3. 测试完成后，合并到 main 和 develop 分支。
  4. 在 main 分支上打标签（Tag），例如 v1.2.3。
  5. 删除发布分支。

5. 代码审查规范 ​

5.1 审查流程 ​

  1. 开发完成后，创建 Pull Request（PR）。
  2. 团队成员进行代码审查，提出修改建议。
  3. 开发者根据反馈修改代码。
  4. 审查通过后，合并代码。

5.2 审查内容 ​

  • 代码是否符合编码规范。
  • 代码是否实现了预期功能。
  • 是否有潜在的 bug 或性能问题。
  • 是否有足够的测试覆盖。

6. 其他规范 ​

6.1 Git 忽略文件 ​

  • 使用 .gitignore 文件忽略不必要的文件（如日志、缓存、依赖目录等）。
  • 确保忽略规则适用于所有开发者。

6.2 冲突解决 ​

  • 在合并分支前，先拉取最新代码，解决冲突。
  • 解决冲突后，运行测试用例，确保代码功能正常。

6.3 工具支持 ​

  • 使用工具（如 commitlint、husky）强制规范提交消息。
  • 使用 CI/CD 工具（如 GitHub Actions、GitLab CI）自动化测试和部署。

7. 示例流程 ​

7.1 开发新功能 ​

  1. 从 develop 创建分支：git checkout -b feature/user-auth。
  2. 开发完成后提交：git commit -m "feat(user): 添加用户登录功能"。
  3. 推送到远程仓库：git push origin feature/user-auth。
  4. 创建 Pull Request，进行代码审查。
  5. 审查通过后，合并到 develop 分支。

7.2 发布新版本 ​

  1. 从 develop 创建分支：git checkout -b release/v1.2.0。
  2. 进行测试和修复。
  3. 测试完成后，合并到 main 和 develop 分支。
  4. 在 main 分支上打标签：git tag v1.2.0。
  5. 推送标签：git push origin v1.2.0。

通过以上规范，可以确保 Git 项目管理的清晰性和高效性。根据团队的具体需求，可以适当调整规范内容。如果有其他问题，欢迎随时讨论！