Git分支代码被意外覆盖后的紧急恢复步骤-git-PHP中文网

能找回，只要未执行git gc或清理.git/logs/，被reset --hard删除的提交仍存在于对象库中；首要任务是通过git reflog定位其sha哈希，再用git checkout或git restore恢复文件。

git分支代码被意外覆盖后的紧急恢复步骤

只要没执行 git gc 或手动清理 .git/logs/，被 git reset --hard “删掉”的提交还在对象库里，只是分支指针跳走了。关键不是“找回代码”，而是“找到那个提交哈希”。

git reflog 是第一反应——它记录了 HEAD 每一次移动，包括你刚敲下的 git reset --hard HEAD~3
在输出里找类似 abc1234 HEAD@{2}: commit: 完成用户鉴权逻辑 这样的行，记下 abc1234
用 git checkout abc1234 -- . 恢复全部文件（不切换分支），或 git restore --source abc1234 --staged --worktree .（Git 2.23+）
如果 reflog 已清空（比如误删了 .git/logs/），立刻试 git fsck --lost-found，它会列出所有悬空 commit，再用 git show <hash></hash> 确认内容

远程仓库被强推后，本地的 origin/main 引用已更新，但旧提交很可能还在远程服务器上（GitHub/GitLab 默认保留 30 天 reflog）。不能直接 git pull，得先定位旧提交。

先查远程分支的历史操作：git reflog show origin/main（不是 git log origin/main）
如果这一步报错或无结果，说明远程 reflog 不可访问，转而联系管理员从备份或仓库后台恢复（GitLab 有“恢复分支”按钮，GitHub 需开 support ticket）
若本地曾 fetch 过旧提交，git log --oneline --all | grep "关键词" 可能快速定位
确认旧提交哈希后，建临时分支：git branch recover-main <old-hash></old-hash>，再 git push origin recover-main:main（需团队协调停写）

恢复过程中最常踩的坑不是命令写错，而是边救边改、多人并发操作、或盲目 git push -f。

审计 GitHub Actions 工作流文件的密钥泄露风险，例如 pull_request_target 密钥使用、密钥回显命令及未固定版本的 Action 密钥传递。

下载

恢复前先 git status 和 git stash 当前未提交修改，防止新改动混入旧历史
不要在恢复分支上直接 git commit —— 先用 git diff <old-hash><new-hash></new-hash></old-hash> 确认差异范围，再决定是 cherry-pick 还是 merge
强制推送前必须确认：目标分支无人正在基于旧历史开发；CI/CD 流水线已暂停；通知 Slack/钉钉群所有人“即将重置 main”
恢复完成后立即 git push origin :refs/remotes/origin/main 清理本地过期 remote tracking 分支，再 git fetch 同步新状态

这个命令依赖 reflog 记录，但 reflog 默认只记录 HEAD 移动，不记录工作区文件的单独修改。它只对“被 Git 跟踪且曾暂存过的文件”有效。

如果 file.js 是新建未 git add 的文件，git checkout 找不到它的历史版本，只能靠编辑器缓存或系统回收站
如果文件已被 git clean -f 删除，reflog 里没有对应快照，git checkout 会报错 pathspec 'file.js' did not match any file(s) known to git
正确姿势：对重要未暂存文件，先 git add file.js 再 git commit -m "WIP"，哪怕只是临时占位
长期预防：启用 IDE 的本地历史（如 VS Code 的 File → Local History），或配置 git config --global core.autocrlf true 避免因换行符触发误 clean