PR 大小

为什么

何时使用

如何做

1. 每 PR 目标 < 400 行
   - 200 行理想——15 分钟审查
   - 400 行上限——30 分钟审查
   - 1000+ 行不能彻底审查——拆

2. 每变更一 PR
   - 一功能、一 bug 修、一重构——非混合
   - 做三事的 PR 是三 PR
   - 若变更无关应分开 PR

3. 大变更拆为 PR 栈
   - PR 1: 加数据模型和迁移
   - PR 2: 加服务层（依赖 PR 1）
   - PR 3: 加 API 端点（依赖 PR 2）
   - PR 4: 加 UI（依赖 PR 3）
   - 每 PR 小且独立可审查

4. 未完成功能用功能标志
   - 标志后合并基础设施，后 PR 启用
   - 这使合小 PR 不暴露功能

5. 使 PR 易审查
   - 写清晰描述: 什么、为什么、如何、测试
   - UI 变更加截图
   - 链 issue 或设计文档
   - 请求审查前自审 diff

示例

// 坏: 1500 行 PR 做一切
// feat: 加用户注册
// - 数据库迁移（200 行）
// - 用户模型（150 行）
// - 邮件服务（300 行）
// - 注册 API（200 行）
// - 欢迎邮件模板（150 行）
// - 注册表单 UI（300 行）
// - 表单验证（200 行）
// 总: 1500 行——不能彻底审查

// 好: 拆为小 PR 栈
// PR 1: feat: 加用户模型和迁移（150 行）
//   - db/migrations/001_add_users.sql
//   - src/models/user.ts
//   - tests/models/user.test.ts

// PR 2: feat: 加邮件服务（200 行）[依赖 PR 1]
//   - src/services/email.ts
//   - src/templates/welcome.ts
//   - tests/services/email.test.ts

// PR 3: feat: 加注册 API（200 行）[依赖 PR 2]
//   - src/api/register.ts
//   - src/api/register.test.ts
//   - 验证输入、创用户、发邮件

// PR 4: feat: 加注册表单（250 行）[依赖 PR 3]
//   - src/components/RegisterForm.tsx
//   - src/components/RegisterForm.test.tsx
//   - src/pages/register.tsx

// PR 描述模板:
"""
## 什么
加带邮箱验证的用户注册。

## 为什么
用户不能创账户——这是最高用户请求。

## 如何
1. 加用户模型和迁移（PR 1）
2. 加欢迎邮件的邮件服务（PR 2）
3. 加注册 API 端点（PR 3）
4. 加注册表单 UI（PR 4）

## 测试
- 模型、服务、API 和表单单元测试
- 全流集成测试
- 手动测: 注册 → 收邮件 → 验证

## 清单
- [x] 加测试
- [x] 无破坏变更
- [x] 自审 diff
"""

常见问题

• ⚠因"功能是一事"开 1000 行 PR——审查者略读、批准、邮件服务 bug 发因无人读那部分。
• ⚠同 PR 混 bug 修和重构——审查者分不清哪些是修哪些是重构，若重构致回归修被怪。
• ⚠拆 PR 但每 PR 依赖前未合并 PR——审查者不合并所有 PR 不能跑代码、审查阻。
• ⚠写一行 PR 描述（"修 bug"）——审查者无上下文、须读 diff 懂变更、审查花两倍长。

最佳实践

• ✓每 PR 目标 < 400 行（200 理想）——研究显审查有效性 400 行以上锐降，小 PR 15 分钟彻底审。
• ✓每变更一 PR——做 bug 修、重构和功能的 PR 是三 PR，混使审查更难坏时更难分怪。
• ✓写清晰 PR 描述（什么、为什么、如何、测试）——审查者需上下文有效审查，好描述半审查时间。
• ✓请求审查前自审 diff——你会抓错字、调试日志和明显问题，审查者时间花你漏的微妙问题。