很多 Git 教程都会告诉你：git reset 很危险，慎用。
但真正让我困惑的不是'危险'，而是：它到底在 reset 什么？
直到一次误 push 的经历，我才第一次把 git reset 用明白。
一、困惑从哪里开始的
如果你在 Git 里搜索 reset，大概率会看到三种写法：
git reset --soft
git reset --mixed
git reset --hard
- 以及一堆警告：
- ⚠️ 不要在公共分支用
- ⚠️ 小心丢代码
- ⚠️ 会重写历史
- 结果就是：大家记住了'危险'，却没真正理解它的行为。
二、理解 reset 的关键：三层世界
真正理解 git reset，必须先接受 Git 的一个事实：
git reset的本质，其实只有一句话：移动分支指针（HEAD），并决定是否同步暂存区和工作区。- 一切复杂性，都是从这里展开的。
Git 并不是只有'代码'和'提交'两层，而是三个世界：
Commit History ← 提交历史（HEAD / branch）
Staging Area ← 暂存区（git add）
Working Tree ← 工作区（你的代码文件）
三、reset 的三种模式，其实是三种'后悔程度'
3.1 git reset --soft：我只是想重来一次提交
git reset --soft HEAD~1
- 效果：
- commit 消失
- 代码还在
- 代码仍然是已 add 状态
- 适合场景：
- 提交信息写错了
- 想把多个 commit squash 成一个
发生的事情：
Commit History ← 回退
Staging Area ← 保留
Working Tree ← 保留
3.2 git reset --mixed：我想重新组织这次提交
git reset HEAD~1
（这是默认模式）
- 效果：
- commit 消失
- 代码还在
- 需要重新
git add
- 适合场景：
- 拆分提交
- 挑选性地 add 文件
发生的事情：
Commit History ← 回退
Staging Area ← 清空
Working Tree ← 保留
3.3 git reset --hard：这次改动我彻底不要了
git reset --hard HEAD~1
- 效果：
- commit 没了
- 代码也没了
- 适合场景：
- 临时 debug
- 实验性代码
- 明确不再需要的改动
发生的事情：
Commit History ← 回退
Staging Area ← 清空
Working Tree ← 回退（⚠️）
四、一次真实经历：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，正是最考验你是否理解这些边界的命令之一。
