结论：未推送用 git reset --hard，已推送必须用 git revert；找 commit hash 应用 git log --oneline -n 20 或 IDEA 右键“Copy Revision Number”；文件级恢复优先用 git restore。
直接说结论：回退到历史版本，不是选“最简单”的命令，而是看“代码有没有推送到远程”——没推就用 git reset --hard，已推就必须用 git revert，混着用会出事。
怎么安全拿到目标 commit hash
别靠截图、手动复制或凭记忆输哈希，极易出错。最稳的三步：
- 运行
git log --oneline -n 20，扫一眼前 20 条，每行开头就是可用的短哈希（如a1b2c3d） - 要完整哈希？用
git log -n 1 --format="%H" a1b2c3d，避免截断 - 在 IDEA 里右键提交 → “Copy Revision Number”，默认复制完整哈希，比终端选中更可靠
注意：git show 和 git status 不列提交历史，不能用来找版本号。
本地未推送时：用 git reset --hard 回退但必须知道后果
这是最快、最彻底的方式，但只适用于你确定没人基于这些提交继续开发的场景（比如个人分支、刚提交还没 push）。
-
git reset --hard a1b2c3d：HEAD、暂存区、工作区全回到该提交状态，之后所有变更（包括未提交的修改）全部消失 - 执行后
git push会失败，报类似error: failed to push some refs to 'origin'，因为 Git 默认禁止非快进推送 - 必须加
-f强推：git push -f origin main；如果远程分支受保护（如 GitHub 的 protected branch），得先去网页关掉 “Require pull request reviews” 等策略 - 误操作后唯一补救是
git reflog，它能找回被--hard丢掉的提交，但git gc运行后就真没了
已推送到远程时：必须用 git revert，否则破坏协作
只要别人可能基于你的提交做了工作，就绝不能用 reset。此时 revert 是唯一合规方式——它不删历史，而是新增一个“反向提交”来抵消变更。
- 撤销单个提交：
git revert a1b2c3d - 撤销连续多个（从旧到新）：
git revert a1b2c3d^..f4e5d6c，注意顺序：越晚的提交越要写在前面 - 撤销 merge 提交时必加
-m 1：git revert -m 1 f4e5d6c，否则报错Commit f4e5d6c is a merge but no -m option was specified -
revert后生成的新提交需手动git push，不加-f
很多人忽略的是：revert 后的冲突必须手动解决并 git add + git revert --continue，卡住不处理会导致后续 revert 失败。
只想恢复某个文件，而不是整个分支
用 git restore（Git 2.23+），比老式 git checkout <commit> -- <file> 更清晰、更安全。
- 从上一次提交恢复单个文件：
git restore --source=HEAD --staged --worktree path/to/file.js - 从某次历史提交恢复：
git restore --source=a1b2c3d --staged --worktree path/to/file.js - 只恢复暂存区（撤销
git add）：git restore --staged path/to/file.js
注意：git restore 不动 HEAD，也不改分支指针，纯属文件级操作；而 git checkout a1b2c3d -- file 在较新 Git 版本中已被标记为“不推荐”，IDEA 也已默认调用 restore。
真正容易被忽略的点是：git reset --hard 和 git revert 解决的是两类完全不同的问题——前者是“我搞错了，把这段历史抹掉重来”，后者是“大家都知道这段历史存在，但我现在要把它逻辑上取消”。选错，轻则同事 pull 报错，重则整条主干历史断裂。
