git reset --mixed是默认模式，重置HEAD和暂存区，保留工作区修改，适用于修正刚提交的错误或拆分提交。
git reset --mixed 是回滚提交但保留修改的最常用方式，它把暂存区重置到指定提交，同时让工作区文件保持原样——也就是你改过的代码还在，只是不再处于暂存状态。
什么时候该用 git reset --mixed
适用于你刚提交了内容，但发现提交信息写错了、漏加了文件，或者想把一次大提交拆成几次小提交。它比 git reset --soft 更“干净”，又比 git reset --hard 更安全，因为不会丢代码。
- 刚执行过
git commit，还没git push，想重新组织这次提交 - 误把调试代码一起提交了，想撤回暂存，手动筛选再提交
- 团队协作中，本地有多次提交但尚未推送到远程，需要调整提交粒度
git reset --mixed 的默认行为就是它
其实 git reset 不带参数时，默认就是 --mixed 模式，所以 git reset HEAD~1 和 git reset --mixed HEAD~1 完全等价。HEAD~1 表示上一个提交，HEAD~2 就是上上个，以此类推。
从 Git 仓库历史中彻底删除文件
下载
|Git删除了文件，但还会在Git 仓库历史中遗留。 - 想要从 Git 历史移除敏感信息（密码、密钥、token、私钥） - 想要删除意外提交的大文件 - 想要重写 Git 历史、移除特定文件的所有痕迹 - 提到 "force push"、"重写 commit 历史" - 需要从所有分支、所有 tag 中删除某个文件
- 运行后，
git status会显示所有被撤回的变更变成 “Changes not staged for commit” - 原来的提交记录从分支历史中消失（仅限本地），但 Git 垃圾回收前仍可通过
git reflog找回 - 如果目标提交有多个父提交（比如 merge 提交），需显式加
--no-ff或避免使用HEAD~n形式，改用具体 commit hash
容易踩的三个坑
看似简单，但几个细节不注意就会白忙活：
- 别在已推送的提交上用——如果对应提交已经
git push到远程，强行 reset 后再 force push 会扰乱协作者的历史，除非你明确知道后果并协调好了 -
HEAD~1不等于 “最后一次提交”：如果当前 HEAD 是 detached（比如 checkout 到某个 commit hash），HEAD~1指向的是那个 commit 的父节点，不是你本地分支的最新提交 - 它只影响当前分支：reset 不会动其他分支指针，也不会清理 stash、reflog 或未跟踪文件；那些 .log、.tmp 文件不会自动恢复或消失，得自己判断要不要保留
真正要注意的，是 reset 后那堆“没暂存的修改”是否还符合你当前开发意图——有时候你以为只是调格式，结果发现中间混进了某次实验性改动，而它正安静地躺在工作区里等着被下次 git add 错误地带走。
