团队协作规范

团队协作规范是一套约定，确保多人开发时代码管理有序、高效。

为什么需要规范

分支命名规范

格式：<type>/<description>

类型：
- feature/  功能开发
  feature/login, feature/user-profile

- fix/      bug 修复
  fix/login-error, fix/memory-leak

- hotfix/   紧急修复
  hotfix/security-issue

- release/  发布准备
  release/v1.2.0

- refactor/ 重构
  refactor/auth-module

- docs/     文档
  docs/api-guide

示例：
feature/user-authentication
fix/payment-timeout
hotfix/critical-security-bug

提交信息规范

格式：<type>(<scope>): <subject>

类型：
- feat:     新功能
- fix:      bug 修复
- docs:     文文档
- refactor: 重构
- test:     测试
- chore:    构建/工具

示例：
feat(auth): 添加用户登录功能
fix(api): 修复接口超时问题
docs(readme): 更新安装说明
refactor(utils): 优化工具函数

Git 工作流程规范

分支策略：GitFlow / GitHub Flow

GitHub Flow（推荐）：
main（保护）→ feature → PR → 审核 → 合入

流程：
1. 从 main 创建 feature 分支
2. 在 feature 开发
3. 推送并创建 PR
4. 通过审核和 CI
5. 合入 main
6. 删除 feature 分支

PR 规范

PR 标题格式：
<type>: <description>

PR 内容模板：
## 变更说明
- 具体变更内容
- 变更原因

## 测试情况
- 测试方法
- 测试结果

## 检查清单
- [ ] 代码符合规范
- [ ] 测试通过
- [ ] 文档更新
- [ ] 无安全风险

## 关联
Fixes #issue

代码审核规范

审核要求：
- 每个 PR 至少 1 人审核
- 重要变更需要 2 人审核
- 必须通过 CI 检查
- 必须解决所有讨论

审核响应时间：
- 普通 PR：< 24 小时
- 紧急 PR：< 4 小时

审核内容：
- 功能正确性
- 代码风格
- 测试覆盖
- 安全检查

代码风格规范

工具配置：
- ESLint / Prettier（前端）
- pylint / black（Python）
- checkstyle（Java）

使用方式：
- 本地开发时自动检查
- 提交前运行检查
- CI 强制检查

配置文件：
.eslintrc.js
.prettierrc
.pylintrc

版本管理规范

语义化版本：MAJOR.MINOR.PATCH

- MAJOR: 不兼容变更
- MINOR: 新功能，兼容
- PATCH: bug 修复

示例：
v1.0.0 → v1.0.1（bug 修复）
v1.0.1 → v1.1.0（新功能）
v1.1.0 → v2.0.0（重大变更）

标签管理：
git tag -a v1.0.0 -m "Release v1.0.0"
git push origin v1.0.0

团队协作清单

提交前：
□ 代码符合风格规范
□ 提交信息符合格式
□ 测试通过

推送前：
□ 拉取最新代码
□ 解决冲突
□ 运行检查

PR 前：
□ 自检代码
□ 填写 PR 信息
□ 关联 Issue

审核时：
□ 及时响应
□ 友好沟通
□ 说明原因

规范文档化

# 项目规范文件
CONTRIBUTING.md    # 贡献指南
README.md          # 项目说明
.github/
  CODEOWNERS       # 代码负责人
  PULL_REQUEST_TEMPLATE.md  # PR 模板
  ISSUE_TEMPLATE.md         # Issue 模板
.eslintrc.js       # 代码风格

规范需要团队共识和持续执行，定期回顾和更新。

要点总结

1. 分支命名：type/description 格式
2. 提交信息：type(scope): subject 格式
3. PR 流程：创建→审核→CI→合并
4. 审核要求：至少 1 人，及时响应
5. 规范文档化：CONTRIBUTING.md