压缩合并与 PR 大小分布的见解总结，由 Claude Code 的创建者 Boris Cherny (@bcherny) 于 2026 年 3 月 25 日发布。
| ← 返回 Claude Code 最佳实践 |  |
Boris 分享了他的 GitHub 贡献图，显示 3 月 24 日有 266 次贡献 —— 来自 141 个 PR，始终压缩合并，每个 PR 的中位数为 118 行。
- 压缩合并将所有分支提交合并到目标分支的单个提交中 —— 保持历史记录干净和线性
- 每个 PR = 一个提交，可以轻松回退整个功能并简化
git bisect - 在高速度的 AI 辅助工作流中（141 PR/天），压缩是务实的选择 —— 分支内的单个"修复 lint"、"试试这个"提交是噪音
Boris 分享了这 141 个 PR 的大小分布，总计 45,032 行更改（添加 + 删除）：
| 指标 | 行数（添加+删除） | 含义 |
|---|---|---|
| p50 | 118 | 中位数 PR 大小 —— 一半的 PR 在 118 行或更少 |
| p90 | 498 | 90% 的 PR 在 500 行以下 |
| p99 | 2,978 | 只有约 1 个 PR 超过约 3K 行 |
| min | 2 | 最小的 PR —— 一个快速的 2 行修复 |
| max | 10,459 | 最大的单个 PR —— 可能是迁移或生成的代码 |
- 118 行的中位数意味着大多数 PR 都很聚焦且可审查，即使在 141 PR/天的速度下
- 分布严重右偏 —— 偶尔的大 PR 不可避免（批量重命名、迁移），但常态是紧致的
- 小 PR 减少合并冲突风险，更容易审查，与压缩合并完美配合便于干净回退
