backup materials and knowledge-base docs

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

@@ -0,0 +1,119 @@
+# 多人协作规范
+
+## 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
+- 至少一人审核通过才能合并
+- 提供建设性反馈
+
+❌ **禁止：**
+
+- 未经审查直接合并
+- 自己审查自己的代码