能，reflog 默认30天内保留被删分支最后一次提交记录，因其仅删除分支引用而非提交对象，通过git reflog --all可查到并用git branch恢复。
reflog 能查到被删分支的最后一次提交吗
能，只要没过 30 天（默认），git reflog 就会保留本地所有 HEAD 移动记录，包括 checkout、merge、reset，当然也包括 git branch -d 或 git branch -D 前那个分支最后一次被检出时的提交。删分支本身不删提交对象，只是删了指向它的引用。
实操建议：
- 立刻运行
git reflog --all，比git reflog更稳妥，避免只看当前分支的记录漏掉目标 - 在输出里找关键词：比如分支名出现在
checkout: moving from xxx to yyy，或某次commit:后跟着你记得的提交简短描述 - 注意时间戳列（如果终端支持），误删前几分钟的记录优先排查
- Windows 上用
git reflog --all | findstr "branch-name"，macOS/Linux 用git reflog --all | grep "branch-name"
用 reflog 创建新分支恢复原分支
找到目标提交哈希（比如 abc1234）后，直接基于它新建分支即可，原分支内容完全还原。
实操建议：
- 确认提交哈希无误：先
git show abc1234看一眼作者、时间、变更文件是否匹配 - 执行
git branch feature/login abc1234（把feature/login换成你要恢复的原分支名） - 如果原分支已存在同名远程跟踪分支（如
origin/feature/login），本地新建后不会自动关联，需手动git branch --set-upstream-to=origin/feature/login feature/login - 别用
git checkout -b替代，它会在创建同时切换，可能干扰当前工作区状态
为什么 git fsck 找不到被删分支的提交
git fsck 只检查“不可达对象”，而刚删的分支提交往往仍被 reflog 引用，属于“可达但无分支名指向”的状态，所以 fsck 默认不报它——这不是 bug，是设计使然。
实操建议：
- 不要依赖
git fsck --lost-found找误删分支，效率低且结果难定位 - 如果 reflog 已被清理（比如执行过
git reflog expire --expire=now --all），才考虑git fsck --unreachable配合git show逐个排查 - 真正安全的做法是：日常定期
git fetch --prune同步远程，再用git branch -r核对远程分支是否存在，避免本地误删后无从回溯
reflog 过期后还有救吗
默认 90 天（非合并提交）或 30 天（合并提交）后，reflog 条目会被 git gc 清理。过期 ≠ 提交被删，只要没人执行 git gc --prune=now，提交对象通常还在 .git/objects 里沉睡。
实操建议：
- 立刻停用该仓库，避免任何写操作（包括
git status可能触发 auto-gc） - 尝试
git fsck --unreachable --no-reflogs，筛选出 type commit 的哈希，再用git show <hash></hash>看是否有熟悉的内容 - 如果项目有 CI 构建记录、IDE 本地历史、甚至编辑器备份文件（如 VS Code 的
.history/），都可能残留提交线索 - 别指望
git reflog expire参数能“延长”已过期的条目——它只影响未来行为
reflog 是第一道防线，但它的窗口很窄；真正容易被忽略的是：很多人删分支前根本没确认远程是否存在同名分支，或者忘了自己刚 push 过但 CI 还没来得及同步。留个 git branch -a 的习惯，比事后抢救省力得多。
