git revert 是“加一笔”而非“删历史”，生成新提交抵消目标变更，适合团队协作；git reset --hard 是“砍掉尾巴”，危险但彻底，仅适用于未推送或全员同步场景。
git revert 是“加一笔”而不是“删历史”
它不会改动已有提交记录，而是生成一个新提交，内容正好抵消目标 commit 的所有变更。适合团队协作场景——别人已经拉过你的代码，你不能偷偷把历史改掉。
- 执行
git revert <commit-id>后，会打开编辑器让你写提交信息，默认是 “Revert \"xxx\"”，直接保存即可 - 如果要撤销多个连续提交，用
git revert <oldest-commit>^..<newest-commit>（注意^表示“不包含起点”） - 遇到冲突？别慌，它和 merge 冲突一样处理：改完文件 →
git add .→git revert --continue - 误操作中断了 revert？可以用
git revert --abort撤回整个 revert 过程
git reset --hard 是“砍掉尾巴”，危险但干脆
它直接把 HEAD、暂存区、工作区全拉回到指定版本，之后的提交在本地彻底消失（除非你记得 commit id，还能从 reflog 找回来）。只适合还没推到远程、或你就是仓库管理员且确认全员同步清理。
-
git reset --hard <commit-id>之后，git log看不到被砍掉的提交；git status显示工作区干净 - 推送到远程必须加
-f：git push -f origin main，否则会被拒绝——因为远程比你“新” - 强制推送前务必确认：有没有别人基于被删提交做了新开发？有就别硬来，改用 revert
- 本地误删又没 commit？
git fsck --lost-found可能救回“悬空对象”，但别依赖这个
reset 的三种模式：soft/mixed/hard 到底差在哪
区别全在“影响范围”：只动 HEAD？连暂存区一起清？还是连工作区文件都还原？很多人只记 hard，却在该用 soft 时硬上 hard，结果白丢修改。
-
git reset --soft <commit-id>：只移动 HEAD，所有后续变更仍在暂存区，适合“哎我提交信息写错了，想重提一次” -
git reset --mixed <commit-id>（默认行为）：HEAD 和暂存区重置，但工作区文件不变，适合“我想重新选择哪些文件进下一次提交” -
git reset --hard <commit-id>：三者全重置，文件内容也倒退回目标版本——这是唯一真正“丢代码”的 reset
线上分支被误 reset -f 覆盖了怎么办
这是最痛的场景：你本地落后，却 git push -f 把远程 main 强制覆盖成旧版，别人刚合入的 PR 全没了。恢复关键不是“怎么 push”，而是“找对版本”。
- 别急着再 push，先去代码平台（如 GitHub/GitLab）点开该分支的 “Insights → Network” 或 “Activity”，翻到最近一次正常推送的 commit id（比如
79b769） - 本地执行
git fetch origin，然后git reset --hard 79b769（确保本地和“正确历史”对齐） - 再
git push -f origin main——这次才是把正确的尾巴推回去 - 如果找不到原始 commit？查
git reflog origin/main（需对方未 gc），或联系其他协作者从他们本地git ls-remote拿 hash
git reflog 只存在本地，且默认 90 天后自动清理。 
