git reset --soft 仅移动 head 指针，保留暂存区和工作目录所有修改，适用于修正提交信息、补漏文件或拆分提交；它不丢代码，只重置提交指针，是三者中最安全的模式。
git reset 不是“撤销操作”的万能按钮，而是精确控制 HEAD、暂存区和工作目录三者状态的底层命令。用错模式，轻则重做半天，重则丢代码——尤其在团队协作中，git reset --hard 推送后几乎无法挽回。
什么时候该用 git reset --soft
你刚执行了 git commit，但立刻发现提交信息写错了、漏了文件、或者想把这次提交拆成两个更小的粒度。
此时 git reset --soft HEAD~1 是最安全的选择：它只把 HEAD 指针移回去，所有修改仍留在暂存区，git status 会显示“Changes to be committed”，你可以直接 git commit --amend 改提交信息，或 git reset（不带参数）取消部分暂存再分批提交。
- 常见错误：误以为
--soft会丢修改——它不会，连暂存区都不碰 - 注意：如果目标提交不是
HEAD~1，而是一个具体哈希（如abc1234），要确认该提交在当前分支可达路径上，否则会报错fatal: ambiguous argument 'abc1234': unknown revision - 不能用于已推送到远程的提交（除非你明确要强制推送并通知协作者）
git reset 默认行为就是 --mixed，别被名字迷惑
执行 git reset HEAD~1 或 git reset --mixed HEAD~1，效果完全一样：HEAD 后退，暂存区清空，但工作目录里的修改原样保留。
这是日常开发中最常用的回滚方式，比如你 git add . 后发现加多了文件，或者一次提交塞了太多逻辑想重新组织。
- 典型场景：
git add src/之后想撤回某个文件？用git reset src/file.js（不带--mixed参数，这是取消暂存的快捷写法） - 性能影响：对大仓库，
--mixed比--hard快得多，因为它不用重写工作目录文件 - 兼容性提醒：某些 GUI 工具（如 VS Code Git 插件）点击“Undo Last Commit”实际调用的就是
--mixed，不是--soft
git reset --hard 的真实代价是什么
它不只是“回到某次提交”，而是把暂存区和工作目录全部硬覆盖为目标提交的状态——所有未提交的修改（包括已 git add 但没 commit 的）都会被立即丢弃，且不进回收站。
唯一能找回的途径是 git reflog，但 reflog 默认只保留 30 天（gc.reflogExpire 配置项），而且本地没推送的记录，别人也帮不上忙。
- 危险信号：终端输出里出现 “Discarding untracked files” 或 “Unstaged changes after reset” 就说明有内容被丢，不是警告，是既成事实
- 正确姿势：先
git stash或git checkout -b backup-branch保存当前状态，再执行--hard - CI/CD 场景下慎用：Jenkins/GitLab Runner 的工作目录通常不保留 reflog，
--hard后基本不可逆
别忽略 git reset 和 git reset HEAD 的本质区别
git reset（无参数）和 git reset HEAD 看似一样，其实前者等价于 git reset --mixed HEAD，只重置暂存区；后者是完整写法，语义更清晰。但两者都不移动 HEAD。
真正容易混淆的是 git reset HEAD~1 —— 它移动 HEAD，同时重置暂存区（默认 --mixed），而 git reset（无参数）只是清空暂存区，HEAD 不动。
- 查错技巧：执行完
git reset后，git log显示的最新提交没变，说明 HEAD 没动；git log往前跳了一格，说明用了HEAD~1类参数 - 参数差异：只有带
<commit></commit>（如HEAD~1、main、abc123）才会移动 HEAD；没它，就只动暂存区 - Git 2.35+ 开始，
git reset --no-keep这类旧参数已被废弃，遇到报错直接删掉
git reset 的复杂点不在语法，而在它对三个区域的耦合控制——你改的从来不是“代码”，而是 HEAD 指针、索引快照和磁盘文件这三层映射关系。每次执行前，先跑一遍 git status 和 git diff --cached，比背口诀管用。
