评审前整理与安全推送

学完这篇你会掌握什么

• 理解 评审前整理与安全推送 的核心作用和适用场景
• 掌握 评审前整理与安全推送 的基本用法和常用参数
• 在发起评审和推送之前，用一套轻量检查动作整理提交栈、确认差异范围，并优先采用更保守的推送方式。
• 理解 为什么"push 前自检"能显著减少事故 相关的概念
• 掌握 1. 发起评审前先整理提交栈 相关的操作
• 知道在什么场景下使用该命令，什么场景下避免使用

先想一个问题

你的团队在 Git 使用上积累了一些习惯，但你不确定这些习惯是否最优——或者你刚经历过一次因为 Git 操作不当造成的事故，想知道怎么避免下次再犯。

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

本地提交

git log 确认提交git diff --staged 检查内容git status 确认干净

→安全推送

推送到远端

git push --dry-run → 预检git push → 正式推送git log origin/main → 确认远端状态

推送是不可逆操作（除非 force push）。推送前的最后检查是你最后的机会。

推送本身不是最危险的，

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. 改写可能影响别人的历史前先沟通

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

给你的练习

1. 在一个测试仓库中练习该命令的基本用法，观察执行前后的状态变化
2. 尝试该命令的不同参数选项，对比输出结果的差异
3. 模拟一个需要使用该命令的实际场景，完整走一遍操作流程

延伸阅读

沿着同一主题继续深入：

• 发布前 Git 卫生专题
• 安全使用 cherry-pick专题
• 安全 force push 协议