【git reset】我终于真正理解了 git reset

​很多 Git 教程都会告诉你：git reset 很危险，慎用。

​但真正让我困惑的不是“危险”，而是：它到底在 reset 什么？

​直到一次误 push 的经历，我才第一次把 git reset 用明白。

一、困惑从哪里开始的

​如果你在 Git 里搜索 reset，大概率会看到三种写法：

git reset –soft
git reset –mixed
git reset –hard

• 以及一堆警告：
  • ⚠️ 不要在公共分支用
  • ⚠️ 小心丢代码
  • ⚠️ 会重写历史
• 结果就是：大家记住了“危险”，却没真正理解它的行为。

二、理解 reset 的关键：三层世界

​真正理解 git reset，必须先接受 Git 的一个事实：

• Git 并不是只有“代码”和“提交”两层，而是三个世界：

  Commit History ← 提交历史（HEAD / branch）
  Staging Area ← 暂存区（git add）
  Working Tree ← 工作区（你的代码文件）

• git reset 的本质，其实只有一句话：移动分支指针（HEAD），并决定是否同步暂存区和工作区。

• 一切复杂性，都是从这里展开的。

三、reset 的三种模式，其实是三种“后悔程度”

3.1 git reset –soft：我只是想重来一次提交

git reset –soft HEAD~1

• 发生的事情：

  Commit History ← 回退
  Staging Area ← 保留
  Working Tree ← 保留

• 效果：

  • commit 消失
  • 代码还在
  • 代码仍然是已 add 状态

• 适合场景：

  • 提交信息写错了
  • 想把多个 commit squash 成一个

3.2 git reset –mixed：我想重新组织这次提交

git reset HEAD~1

（这是默认模式）

• 发生的事情：

  Commit History ← 回退
  Staging Area ← 清空
  Working Tree ← 保留

• 效果：

  • commit 消失
  • 代码还在
  • 需要重新 git add

• 适合场景：

  • 拆分提交
  • 挑选性地 add 文件

3.3 git reset –hard：这次改动我彻底不要了

git reset –hard HEAD~1

• 发生的事情：

  Commit History ← 回退
  Staging Area ← 清空
  Working Tree ← 回退（⚠️）

• 效果：

  • commit 没了
  • 代码也没了

• 适合场景：

  • 临时 debug
  • 实验性代码
  • 明确不再需要的改动

四、一次真实经历：reset 为什么救了我

​我曾经在一个 feature 分支上，误把一条调试日志提交并 push 了出去。

​那一刻我意识到这条提交不应该存在于任何历史中。

​因为这是个人分支、最新提交、且无人依赖，我选择了：

git reset –hard HEAD~1
git push –force-with-lease

• 结果是：
  • 本地历史干净
  • 远程历史同步
  • 像什么都没发生过一样
• 这一次操作，让我第一次意识到：reset 并不是“危险操作”，它只是一个“边界操作”。

五、什么时候你不该用 reset？

​判断标准其实只有一句话：你有没有在重写“别人的历史”？

​很多人对 git reset 的恐惧，来源并不是命令本身，而是不清楚这条命令的影响边界。

​一旦你意识到：Git 历史不仅是技术对象，更是一种协作契约，判断就会变得非常清晰。

5.1 公共分支：历史是一种“约定”，不是草稿

​在 main / develop 这类公共分支上，每一次提交，都是对团队的承诺。

• 每一个 commit hash，都可能已经存在于：

  • 他人的本地仓库
  • 自动化测试
  • 发布流水线
  • 线上问题回溯记录中

• 这意味着：一旦你 reset 并 force push， 你修改的不只是代码，而是他人已经基于其构建的现实。

• 因此，在公共分支上：

  • ❌ 不要 git reset

  • ❌ 不要 git push –force

  • ✅ 使用 git revert

    git revert <commit>
    git push

• 哪怕历史变得“不好看”，也比让协作关系失效要好得多。

5.2 已被他人 pull 的提交：reset 会制造“平行宇宙”

​一旦某个提交已经被他人 pull，对方的本地历史中已经包含这个 commit
​此时，如果你再 reset 并 force push，本质上是在告诉 Git：“同一个分支，现在有两个互不兼容的现实。”

• 其后果往往是：
  • 对方 git pull 失败
  • 需要手动 rebase / reset
  • 甚至误以为是自己操作失误
• 而最糟糕的地方在于：错误往往不会立刻显现，而是在之后的某次 push 中爆炸。
• 这也是为什么团队中常说：“不要随便 force push，你可能正在给别人埋雷。”

5.3 CI / CD 正在使用的 commit：历史是“可追溯性”的基础

• 在现代工程实践中，一个 commit 往往不仅仅是代码快照：
  • 它可能对应一次 CI 构建
  • 一次测试报告
  • 一个制品版本
  • 甚至一次线上发布
• 如果你 reset 掉这样的提交：
  • 日志会指向一个不存在的 commit
  • 回滚、审计、复盘都会变得困难
  • “这次发布基于哪次提交？”这个问题将失去确定答案
• 在这些场景下：历史的稳定性，远比整洁性更重要。

5.4 为什么 git revert 是“协作友好型”的选择？

​git revert 的核心特点只有一个：它不修改已有历史，只是在历史之上追加新的事实。

A ── B ── C ── D (bad commit)
│
└── R (revert commit)

• 这意味着：
  • 所有人看到的都是同一条连续时间线
  • 不会出现“有人有 D，有人没有 D”的历史分裂
  • 不需要额外沟通或人工修复他人的仓库状态
• 是的，revert 会让历史看起来不那么“干净”，但它清楚地表达了一件事：这个提交曾经存在过，并且被明确地撤销了。
• 在协作场景中，可追溯、可解释的历史，比表面上的整洁更重要。

5.5 一个我现在遵循的简单原则

​现在，我对是否使用 reset 的判断原则非常简单：如果我需要提前在群里解释我为什么要这么做， 那我大概率就不该这么做。

• 需要解释 → 用 revert
• 不需要解释 → reset 可能是合理的

六、一个后悔药：reset 也不是不可逆的

​即使你 reset 错了，大多数情况下也能通过git reflog找回。

​你会看到类似：

HEAD@{1}: commit: debug: add logs

​然后：

git reset –hard HEAD@{1}

​Git 其实比你想象中更宽容。

七、我现在如何看待 git reset

​现在我对 git reset 的态度只有一句话：它不是用来“修复错误”的，而是用来“整理历史”的。

• 一旦你清楚：
  • 自己在哪个分支
  • 是否影响他人
• git reset 反而是一个非常冷静、非常理性的工具。

写在最后

​很多人害怕 Git，并不是因为 Git 难，而是因为：我们在不知道边界的情况下，被迫做选择。

​一旦边界清晰，选择就会变得简单。而 git reset，正是最考验你是否理解这些边界的命令之一。