评审前整理与安全推送

为什么“push 前自检”能显著减少事故

很多 Git 问题都不是不会命令，而是在真正把历史发出去之前，没有留出最后一分钟做检查。评审前整理和安全推送，本质上是在给历史增加一道低成本的质量门。

1. 发起评审前先整理提交栈

在工作还没共享出去之前，可以先问自己：

1. 这些提交顺序是否讲得通？
2. 有没有明显的噪声提交？
3. reviewer 能不能从历史里看懂决策过程？

如果答案不理想，可以在本地先做整理：

• git commit --amend
• git rebase -i
• git restore --staged

目标不是“把历史修饰得很好看”，而是让提交栈变得可读、可审、可回滚。

2. push 前最小检查清单

一个非常轻量但有效的检查清单：

git status
git log --oneline --decorate -5
git diff --stat origin/main...

这三步能帮助你快速确认：

• 工作区是不是干净
• 最近几个提交是不是你打算发出的内容
• 本次改动规模是不是超出预期

如果你怀疑有无关文件混进来，再补一条：

git diff --name-only origin/main...

3. 为什么 reviewer 关心的不只是代码

reviewer 不只是看“代码能不能跑”，还会看：

• 提交边界是否清晰
• 是否把不相关修改混在一起
• 历史是不是已经乱到难以评论

所以整理提交栈本质上也是在降低 review 成本。

4. 默认使用更安全的推送方式

如果需要强推，优先：

git push --force-with-lease

它比裸 --force 更适合团队环境，因为它会先检查远端是否仍然处于你理解的状态。

如果你并不需要重写远端历史，就不要把 force 当快捷键。

5. “能 push”不等于“现在就该 push”

下面这些情况，最好先停一下：

• 还有未解释清楚的噪声提交
• 最近一次 rebase 之后还没重新看 diff
• 你不确定远端是否已经被别人更新
• 你打算强推，但还没通知相关协作者

这类暂停通常只要几十秒，但能省掉后面大量沟通成本。

6. 一个适合团队共识的推送底线

你可以把规范先收成这五条：

1. push 前先看 git status
2. push 前先看最近几条提交
3. 发评审前先整理噪声提交
4. 强推默认使用 --force-with-lease
5. 改写可能影响别人的历史前先沟通

这五条规则很轻，但对团队协作的改善通常非常明显。