撤销Git提交的核心原则是：未push用git reset，已push优先用git revert； amend仅改信息或补文件；force-push高风险，须谨慎。

简单来说，撤销 git commit 的核心逻辑取决于代码的“可见范围”：如果提交还躺在本地，没推送到远程，那么 git reset 是你的首选；一旦已经 push 出去，成了公共历史的一部分，git revert 就是更安全、更负责任的做法。至于强行 reset --hard 后再 push --force-with-lease，那属于高风险操作，仅限于你完全掌控该分支，并且能百分百确认没有其他协作者基于它进行后续开发时，才值得考虑。

只想改提交信息或补文件？用 git commit --amend

这可能是最轻量、也最安全的“撤销”方式了——它并不真正删除任何东西，只是把上一次提交替换成一个新的快照。

• 适用场景：刚执行完 git commit -m "fix bug"，突然发现漏加了一个关键文件 utils.js，或者提交信息里有个恼人的错别字。
• 执行前准备：确保漏掉的文件已经通过 git add utils.js 加入了暂存区（否则命令只会修改提交信息）。
• 操作步骤：直接运行 git commit --amend，默认的文本编辑器会打开，里面是上一次的提交信息，修改后保存即可完成替换。
• 快捷方式：如果只想修改信息而不动文件，可以用 git commit --amend -m "fixed typo in message" 直接指定新信息，跳过编辑器。
• 关键提醒：--amend 的本质是“重写最后一次提交”，所以它会生成一个全新的提交哈希值。如果这个提交已经被 push 到远程，后续你将不得不使用 git push --force-with-lease 来更新远程分支。

已 push 到远程，要安全撤回某次提交？用 git revert

git revert 的设计哲学很巧妙：它不直接抹去历史，而是通过新增一个“反向提交”来抵消某次更改的效果。这使其成为团队协作中唯一被广泛推荐的撤回方式。

• 撤销最近一次提交：git revert HEAD。撤销指定提交：git revert abc1234。
• 撤销连续多个提交：比如想撤销倒数第2次和第1次提交，命令是 git revert HEAD~2..HEAD（注意是两个点，不是三个）。
• 处理冲突：revert 操作可能会引发冲突。如果被撤销的那个 commit 所修改的文件，在之后的提交中又被改动过，Git 就无法自动计算出完美的“反向”修改，这时它会停下来，等待你手动解决冲突。解决后，依次执行 git add . 和 git revert --continue 即可。
• 同步到远程：revert 完成后，直接执行 git push 即可，不需要附加 --force 参数，因为它本质上就是一个普通的新提交。
• 反面教材：对已经 push 的提交使用 reset --hard 再强行 push --force。这种做法会直接改写公共历史线，很可能破坏其他协作者本地的仓库状态，引发一系列混乱。

本地还没 push，但想彻底丢弃这次提交和所有改动？慎用 git reset --hard

这个命令威力巨大，它会同时清空你的工作区、暂存区，并将 HEAD 指针回退。被它删除的代码无法通过 git status 找回，通常只能依靠 git reflog 来紧急救援。

• 执行前的灵魂三问：未提交的修改真的都不要了吗？IDE 有没有自动保存？临时文件备份了吗？
• 常用命令：git reset --hard HEAD~1（删除最近一次提交），或者 git reset --hard abc1234（回退到指定的 commit 状态）。
• 误删后的恢复：如果操作后立刻后悔，马上运行 git reflog，找到目标 commit 的哈希值（比如 abc1234），然后再次执行 git reset --hard abc1234 就能恢复。
• 重要限制：reflog 默认只保留最近90天的操作记录，并且这些记录不随仓库克隆而转移。对于长期没有操作的分支，其 reflog 记录可能已经被 Git 的垃圾回收机制清理掉。

撤销后 push 被拒：rejected non-fast-forward 怎么办？

出现这个错误，通常意味着你本地修改了提交历史（比如用了 reset 或 rebase），而远程仓库上已经有了别人推送的新提交。Git 这是在阻止你覆盖他人的工作成果。

• 绝对不要这样做：直接使用 git push --force。这个命令可能会静默地覆盖同事刚刚推送上去的代码，是团队协作的“大杀器”。
• 推荐做法：使用 git push --force-with-lease origin main。这个命令更聪明，它会先检查远程分支的最新提交是否与你本地记录的一致。如果不一致（说明有别人推送了），它会中止推送，从而避免误覆盖。
• 如果已经冲突：先执行 git fetch origin 拉取最新的远程状态。然后根据情况决定，是将你的修改 rebase 到新的远程基础上，还是放弃强制推送，改用更安全的 revert 来达成目的。
• 团队通知：在团队环境中，一旦你使用了 --force-with-lease 强制更新了远程分支，记得通知其他协作者。他们可能需要执行 git fetch && git reset --hard origin/main 来同步本地状态（当然，前提是他们确认可以丢弃本地所有未推送的提交）。

说到底，选择哪种撤销方式，核心判断依据在于“这段历史被谁看到了”。代码还在本地，你就是唯一的读者，操作自由度很高；一旦 push 出去，那段提交历史就成了一份公共契约——revert 是在这份契约上添加一份补充说明，而 reset + force-push 则相当于单方面撕毁契约，其带来的沟通和协调成本，远不止在命令行里多敲几个字那么简单。