# 多人协作规范

## Pull Request 规范

创建 PR 时应包含以下内容：

```markdown
## 变更说明
<!-- 描述本次变更的内容和目的 -->

## 变更类型
- [ ] 新功能 (feat)
- [ ] Bug 修复 (fix)
- [ ] 代码重构 (refactor)
- [ ] 文档更新 (docs)
- [ ] 其他

## 测试方式
<!-- 描述如何测试这些变更 -->

## 关联 Issue
Closes #xxx

## 检查清单
- [ ] 代码已自测
- [ ] 文档已更新
- [ ] 变更已添加到 CHANGELOG
```

## Code Review 规范

### 审查要点

#### 1. 代码质量

- 代码是否清晰易读
- 命名是否规范
- 是否有重复代码

#### 2. 逻辑正确性

- 业务逻辑是否正确
- 边界条件是否处理
- 异常情况是否考虑

#### 3. 安全性

- 是否有安全漏洞
- 敏感信息是否暴露
- 输入是否校验

#### 4. 性能

- 是否有性能问题
- 资源是否正确释放
- 算法复杂度是否合理

### 反馈格式

```markdown
<!-- 必须修改 -->
🔴 **必须修改**: 这里有 SQL 注入风险，需要使用参数化查询

<!-- 建议修改 -->
🟡 **建议修改**: 这个方法可以提取为工具函数，提高复用性

<!-- 讨论 -->
💬 **讨论**: 这里是否可以考虑使用缓存？

<!-- 赞 -->
👍 **赞**: 这个封装很优雅！
```

## 最佳实践总结

### 提交规范

✅ **推荐：**

- 使用 Conventional Commits 规范
- 提交消息清晰描述改动
- 一次提交只做一件事
- 提交前进行代码检查

❌ **禁止：**

- 提交消息模糊不清
- 一次提交多个不相关改动
- 提交敏感信息（密码、密钥）
- 直接在主分支开发

### 分支管理

✅ **推荐：**

- 使用 feature 分支开发
- 定期同步主分支代码
- 功能完成后及时删除分支
- 使用 `--no-ff` 合并保留历史

❌ **禁止：**

- 在主分支直接开发
- 长期不合并的功能分支
- 分支命名不规范
- 在公共分支上 rebase

### 代码审查

✅ **推荐：**

- 所有代码通过 Pull Request
- 至少一人审核通过才能合并
- 提供建设性反馈

❌ **禁止：**

- 未经审查直接合并
- 自己审查自己的代码
