blob: 76cb4a3f83d365e0246e19366ada1cac684c6c9b (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
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
- 至少一人审核通过才能合并
- 提供建设性反馈
❌ **禁止：**
- 未经审查直接合并
- 自己审查自己的代码
|
