Git 提交误丢后怎么找回，用 reflog 建立恢复分支
执行 reset、rebase 或切换分支后，git log 里看不到某个提交，不代表提交对象立刻消失。只要本地仍保留相关对象和引用变更记录，就可能通过 reflog 找回。下面的流程先检查，再建立新的恢复分支，不移动当前分支，也不向远程推送。操作对象应是自己信任的本地仓库。
先保护当前现场
git status --short --branch git log --oneline --decorate -n 10 git reflog show --date=iso -n 30
确认当前目录、分支和未提交改动。若还有重要内容，先把整个项目连同隐藏的 .git 目录备份到安全位置；需要真正备份时，另建 worktree 不能替代独立副本。排查期间避免执行清理对象、清空 reflog 或强制重置等操作，也不要反复试用不明来源的恢复命令。
定位候选提交，而非盲选前一条
reflog 记录本地引用曾指向的位置，HEAD 的记录还包括分支切换。根据故障发生时间、操作说明和提交信息寻找候选；必要时增加显示条数。HEAD@{1} 只是前一次记录，不保证就是正确版本，后续操作还会改变序号。选中后使用固定的提交哈希核对：
# 将 COMMIT_HASH 替换为 reflog 中找到的真实提交哈希 git show --stat --summary COMMIT_HASH git show COMMIT_HASH
先看文件列表、提交说明，再看具体差异，必要时查看该提交下的目标文件。作者与日期只能作为线索，不能代替内容核对。若需要恢复一串提交，应找到能够包含这些工作的正确分支端点，而不是只凭某条提交标题决定。
创建一个新的恢复入口
图：在核验候选提交后新增恢复分支引用，不移动当前分支；提交节点为概念示意。
git branch recovery-20260930 COMMIT_HASH git log --oneline --decorate -n 10 recovery-20260930
创建分支只是新增一个指向提交的引用，不会切换当前分支或覆盖工作区。分支名已存在时请换一个新名称，不要加 -f 强行覆盖。确认日志中能看到需要的提交后，重要内容就有了明确的分支入口。
需要检查文件时使用独立工作目录
如果想打开恢复版本，选择一个尚不存在的相邻目录。下面会为恢复分支建立新的工作区，原工作区保持原状：
git worktree add ../repo-recovery-20260930 recovery-20260930 git -C ../repo-recovery-20260930 status --short --branch
在新目录检查文件，并按项目现有说明运行适用的测试。确认恢复内容后，再决定是合并整个分支、挑选提交，还是仅取回个别文件。涉及共享分支时，先与协作者确认历史处理方式，不要直接强推。含子模块或特殊工作区配置的仓库，应先查看对应限制。
reflog 的恢复边界
reflog 属于本地仓库，不会因为重新 clone 就自动带回来，也不能保证恢复从未提交或保存过的编辑。记录存在过期机制，提交对象也可能被清理，因此发现问题后应尽早保全现场。查不到时继续检查其他本地分支、远程已有提交、同事的副本、IDE 本地历史或备份；这些是补充来源，不代表一定能够恢复。
