docs

Git 使用规范

本规范适用于本团队在 GitHub 上托管的所有项目，旨在确保代码管理一致性、提高协作效率，并配合 CI/CD 流程顺利运行。

如果需要快速了解，请参考新成员 Git 工作流程示例。

我们采用简化版的 Git Flow，结合自动化部署流程，定义以下主要分支：

特殊项目（如客户仓库）应参考客户提供的 Git 规范调整分支命名与流程。

如果没有特殊情况，每个人应当在自己的分支上进行开发工作。

团队统一采用 Conventional Commits 规范，提交信息格式如下：

<type>(<scope>): <subject> #任务编号

<body>（可选）

<footer>（可选）

示例：

feat(auth): 添加用户登录接口 #123

- 支持用户名密码登录
- 添加 jwt token 返回机制

使用 #123 的形式引用任务系统编号（如 Jira、Tapd、禅道等），如未集成自动识别，则建议在 PR 描述中补充任务信息。

所有代码必须通过 Pull Request / Merge Request 合并，不允许直接向 main、develop 等核心分支推送。
提交 PR 时建议遵循以下流程：
1. 拉取最新 develop 或 staging，基于其创建分支；
2. 命名分支：feature/login-ui、bugfix/login-crash 等；
3. 完成开发后提交 PR，并附带清晰描述和任务编号；
4. 合并后删除已完成分支。
Code Review：当前不强制评审，但推荐：
- 关键模块由至少一人审核；
- 后续可引入自动化流程如 CODEOWNERS 管理 Reviewer；
- 保持良好的团队沟通，逐步推动规范化评审。
合并权限：
- 可自我合并，但需确保：
  - CI 检查通过；
  - 代码无冲突；
  - 评估风险较小或已被关注。

示例：

v1.0.0
v1.1.3