BZJZ_Material/文档润色流和知识库构建流/claude-scholar/skills/git-workflow/references/collaboration.md

多人协作规范

Pull Request 规范

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

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

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

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

## 关联 Issue
Closes #xxx

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

Code Review 规范

审查要点

1. 代码质量

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

2. 逻辑正确性

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

3. 安全性

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

4. 性能

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

反馈格式

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

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

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

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

最佳实践总结

提交规范

✅ 推荐：

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

❌ 禁止：

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

分支管理

✅ 推荐：

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

❌ 禁止：

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

代码审查

✅ 推荐：

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

❌ 禁止：

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