Git reset 的三个模式：移动 HEAD 之后还会发生什么

记忆 Git reset 最有效的方法不是背命令，而是先分清三个状态：提交历史由 HEAD 指向，暂存区保存下一次提交内容，工作区则是正在编辑的文件。

三种模式

git reset --soft <commit> 只移动 HEAD，暂存区和工作区保持不变。它适合撤销提交后重新整理提交说明或合并提交。

git reset --mixed <commit> 是默认模式：移动 HEAD，并把暂存区重置到目标提交，但保留工作区修改。原提交中的改动会回到“未暂存”状态。

git reset --hard <commit> 同时重置 HEAD、暂存区和工作区。未提交修改可能被直接覆盖，因此必须先确认目标和备份方式。

soft  ：只动提交历史
mixed ：提交历史 + 暂存区
hard  ：提交历史 + 暂存区 + 工作区

reset 与 revert 的区别

reset 改写分支指针，适合尚未共享的本地历史；revert 会创建一个反向提交，保留原有历史，更适合已经推送并被团队成员使用的分支。

如果错误提交已经进入公共主分支，直接 reset 再强推会让其他人的历史分叉。此时优先使用 revert。只有明确知道远端影响，并与协作者沟通后，才考虑改写公共历史。

误操作后的恢复

Git 通常会通过 reflog 记录 HEAD 最近移动位置：

git reflog
git reset --hard <原提交>

但 reflog 不是鼓励冒险的保险。执行 hard reset 前，先运行 git status、确认绝对仓库位置，并为重要修改创建临时分支或 stash，成本远低于事后恢复。

我的操作原则是：未共享历史可以整理，已共享历史优先追加修复；涉及 hard 与 force push 时，先确定会影响哪些文件和协作者。