PR 前如何整理提交历史

PR 前整理提交，不是为了把历史“修漂亮”，而是为了让 review 更容易、回滚更清楚、后续排障更轻松。
真正高质量的 PR，往往在提交历史还没进 review 之前就已经把噪声压掉了。

先确认

主线最新状态本地提交列表工作区边界

→sync → clean up → verify

PR 应该具备

提交意图清楚diff 边界干净历史风险可控

整理提交不是表演技巧，而是 review 质量的前置条件。

为什么 PR 前需要先整理历史

很多 review 困难，并不是因为代码本身太复杂，而是因为提交历史太吵：

• 中间夹着很多临时修补提交
• 标题无法独立表达意图
• 无关改动混在一起
• 主线已经前进，但分支还停留在旧基底

这些问题一旦带着进入 PR，reviewer 就会把大量注意力花在“你到底想改什么”上，而不是“这个改动值不值得合”。

推荐顺序

1. 先同步主线最新状态

git fetch origin
git rebase origin/main

如果团队更倾向 merge，这里也可以换成 merge。
重点不是必须 rebase，而是你得先知道当前分支和主线到底是什么关系。

2. 整理明显噪音提交

这类提交通常包括：

• fix typo
• oops
• address review
• “试一下能不能过 CI”式提交

在 PR 前，这类噪音能整理就尽量整理掉，避免 reviewer 被历史碎片打断。

3. 再检查提交信息和变更边界

真正该问的是：

• 每个提交能不能独立表达意图
• 提交边界是否和代码意图一致
• 有没有把格式化、重命名、功能变更混在一起

4. 最后确认有没有共享历史风险

如果这段历史已经被别人基于它继续工作，那你此时再 rebase 或重写提交，就已经不是单纯的“整理”，而是在改写共享上下文。

一个保守流程

git fetch origin
git rebase origin/main
git log --oneline --decorate -n 10
git diff --stat origin/main...

这几步能帮助你同时看清：

• 基底是否已经对齐
• 最近提交是否还带明显噪音
• 变更范围是不是和你准备提交的 PR 叙述一致

PR 前最值得确认的 4 件事

1. 是否还有明显的“修修补补”提交可以整理
2. 提交标题是否能独立表达意图
3. 有没有把无关改动混进来
4. 这段历史是否已经被别人基于它继续工作

什么时候“不整理”反而更稳

并不是所有 PR 前都适合再动历史。以下场景要更谨慎：

• 当前分支已共享给别人
• review 已经开始，别人已基于当前提交评论
• 团队不鼓励 review 途中改写历史
• 当前更重要的是尽快交付，而不是继续优化提交颗粒度

也就是说，整理历史是手段，不是教条。

!不要在 review 已经展开之后大幅重写历史

如果 reviewer 已经基于当前提交顺序做了大量评论，大幅 rebase 或改写会让评论上下文迅速失效。PR 前整理最值钱，PR 中途大整理则要非常谨慎。

常见误区

把整理提交理解成“越少越好”

不是提交越少越好，而是每个提交的意图越清楚越好。

只改提交标题，不改提交边界

标题写得再好，如果一个提交里混了三件不同事情，review 还是会痛苦。

没看主线状态就开始整理

基底都没对齐，越早整理，后面越可能要再整理一次。

→PR 前用这 4 句自查

1. reviewer 能不能从提交标题看懂每一步意图？
2. 这组提交是不是还带着明显噪音？
3. 当前 diff 范围是不是和 PR 说明一致？
4. 我现在整理历史，会不会影响已经共享出去的上下文？

一个原则

提交历史不是写给 Git 看的，是写给未来的 review、回滚和排障看的。