git reset --soft仅移动HEAD、保留暂存区和工作区，适用于修改提交信息或补漏文件等场景；对未git add的修改无效，且不可用于已推送至远程的提交。
git reset --soft 什么时候能用、什么时候不能用
它只移动 HEAD 指针，不碰暂存区和工作区，所以适合“改提交但不想重写文件”的场景。比如刚 git commit 完发现漏了文件或提交信息写错，立刻 git reset --soft HEAD~1，再 git commit --amend 就能补上。
但要注意：它对“没 git add 过的修改”完全无效。那些改动还在工作区，但不在暂存区里，--soft 看不见也留不住——你执行完它，那些未暂存的改动依然存在，但不会自动进暂存区。
- ✅ 安全：绝不会丢代码，也不会改磁盘文件
- ❌ 误用：以为它能恢复“没 add 的修改”，结果一通操作后发现那些改动还在，只是没被包含进新提交
- ⚠️ 配合
git commit --amend才完整，单独用--soft只是半步操作
git reset 不带参数（即 --mixed）为什么最容易踩坑
这是默认行为，也是日常最常触发误操作的模式。它会移动 HEAD、清空暂存区，但保留工作区所有改动。表面看是“退回一步”，实际效果是把所有已 git add 的文件从暂存区踢出来，变成“已修改未暂存”状态。
典型翻车现场：想撤销某个 git add，却输成 git reset（没跟文件名），结果整个暂存区被清空；或者想回退一次提交，却忘了加 --hard，改完发现代码还在，但提交没了，暂存也没了，得重新 git add。
- ✅ 合理用途：取消全部暂存、准备重新选择要提交的文件
- ❌ 常见错误：在
git status显示 “Changes to be committed” 时，直接敲git reset，导致所有暂存丢失 - ? 记住：不带参数的
git reset等价于git reset --mixed HEAD，不是“什么都没动”
git reset --hard 的危险点在哪
--hard 会同步重置 HEAD、暂存区和工作区三者，强制把磁盘上的文件覆盖为目标提交的内容。这意味着所有未提交的修改——无论是否 git add 过——都会被直接丢弃，且不可逆（除非靠 git reflog 恢复）。
它不是“删掉提交”，而是让分支指针跳走，同时抹掉你本地还没 commit 的所有痕迹。一旦推送到远端又强制推送（git push --force），别人 git pull 就可能出问题，尤其在共享分支上。
- ✅ 必须用的场景：确认某段开发完全废弃，想彻底回到干净状态（比如拉错分支后一堆乱改）
- ❌ 绝对禁止：在团队共用分支（如
main、develop）上直接--hard后--force push - ⚠️ 关键提醒：
--hard后如果没及时git reflog查记录，2 周内虽大概率能找回，但依赖 Git 自动 gc 时间窗口，别赌
reset 和 revert、restore 混用时怎么不出错
核心判断依据是“改动在哪”：工作区改乱了 → git restore；暂存错了 → git restore --staged 或 git reset（--mixed）；已提交但想撤回 → 本地用 git reset --soft，已推送到远端就用 git revert。
很多人卡在“该用 reset 还是 revert”，其实只看一点：这个提交有没有被别人拉过。只要 git push 过，就别动 reset，否则历史被改写，协作就断了。而 git revert 是安全的“反向提交”，不影响原有链路。
- ✅ 推荐组合：
git restore --staged <file></file>替代老式git reset HEAD <file></file> - ❌ 常见混淆：
git reset <file></file>是取消暂存，不是还原文件内容；还原内容得用git restore <file></file> - ? 记住口诀：“没提交用 restore，已提交看推送，推过了就 revert”
