撤销最近一次commit但保留工作区修改用git reset --soft head~1；改message推荐git commit --amend；已push需用git revert生成反向提交；误删文件可用git checkout head~1 -- file或git reflog找回；push失败时优先用git push --force-with-lease。
撤销最近一次 commit，但保留工作区修改
用 git reset --soft HEAD~1，它只回退 commit 指针，不碰暂存区和工作区。适合刚提交完发现漏了文件、或者想改 commit message 的情况。
常见错误是误用 --hard，结果把刚写的代码也清掉了；--mixed（默认）会重置暂存区，导致已 git add 的文件变成未暂存状态，容易漏提交。
- 如果只想改 message，直接
git commit --amend更安全，不用记参数 -
HEAD~1可换成具体 commit hash，比如git reset --soft abc1234 - 这个操作只影响本地仓库，push 过的记录不会被自动覆盖
已经 push 到远程，怎么安全撤回
不能直接 git reset --hard 后强制 push，除非你确定没人基于那个 commit 继续开发。更稳妥的做法是 git revert：它生成一个新 commit，内容是“把上次提交的改动全部反向应用”。
比如撤销最近一次提交：git revert HEAD；撤销某次特定提交：git revert abc1234。这个操作不改变历史线性结构，适合团队协作环境。
- 如果要撤销连续多个 commit，用
git revert HEAD~2..HEAD（注意是两个点，不是三个） - revert 可能触发冲突，尤其是被撤销的 commit 修改过后来又被改过的文件
- revert 后记得
git push，不需要--force
误删文件后 commit 了，怎么找回
如果只是删了文件并 commit，没做其他操作，最快是 git checkout HEAD~1 -- path/to/file，从上一个 commit 把文件取回来，再重新 add & commit。
使用 `gh` CLI 与 GitHub 交互。通过`gh issue`、`gh pr`、`gh run` 和 `gh api` 管理 issue、PR、CI 运行以及高级查询。
但如果已经 reset 或 revert 过多次，HEAD 指针可能不对，就得找原始 commit hash。用 git reflog 查操作日志，找到删文件前的 commit 记录，再 git checkout abc1234 -- file。
-
git checkout在 Git 2.23+ 被标记为“deprecated”，但目前仍可用；替代方案是git restore --source=HEAD~1 -- file - 注意
git checkout后面的--不能省，否则 Git 可能把它当成分支名解析 - 如果文件在多个 commit 中被反复修改，reflog 是唯一能快速定位“删之前最后一次存在”的方式
撤销 commit 后 push 失败：rejected non-fast-forward
这是 Git 在阻止你用非快进方式覆盖远程历史。出现说明你本地做了 reset 或 rebase，而远程已有别人基于原 commit 的新提交。
强行覆盖要用 git push --force-with-lease（推荐），它比 --force 安全：如果远程有你不知道的新提交，会中止推送，避免意外覆盖他人工作。
- 永远不要对公共分支（如
main、develop）用--force -
--force-with-lease不起作用时，先git fetch，看是否有人新推了东西，再决定是合并还是协调 - 有些团队禁用 force push，这时只能用
revert补救
真正麻烦的不是撤销动作本身，而是搞不清当前 HEAD 指向哪、有没有人基于你的 commit 继续开发、以及远程分支是否受保护。多看一眼 git log --oneline -n 5 和 git status，比背命令有用得多。
