清理Git仓库垃圾：孤立Commit（Dangling Commits）与无主分支的回收机制-git-PHP中文网

git fsck --lost-found 能找回未被任何引用指向的 dangling commit、blob 或 tree 对象，即删除分支、reset --hard、detached head 提交、rebase 或 amend 后遗留的孤儿对象，前提是尚未被 git gc 清理。

清理git仓库垃圾：孤立commit（dangling commits）与无主分支的回收机制

git fsck --lost-found 能找回哪些“丢失”的提交？

它只找那些没被任何引用（分支、标签、HEAD）指向的 commit、blob 或 tree 对象，也就是真正的“孤儿”。这些对象通常来自：删除分支后未合并的提交、git reset --hard 后丢掉的 HEAD 指向、分离头状态下的新提交、git rebase 或 git commit --amend 重写历史时被覆盖的老提交。

注意：git fsck --lost-found 不会列出已被 git gc 清理掉的对象——它只扫描当前 Git 对象数据库里还存活着的 dangling 对象。如果很久没运行过 git gc，这类对象往往还在；但如果你刚执行过 git gc --prune=now，它们可能已经彻底消失。

运行后，输出类似：

Checking object directories: 100% (256/256), done.
dangling commit abc1234567890abcdef01234567890abcdef01234
dangling blob fedcba9876543210fedcba9876543210fedcba98

其中 dangling commit 行就是你要关注的——那个长哈希就是你曾经做过但“消失”的提交 ID。

怎么确认一个 dangling commit 是你需要的？

光看 SHA1 没法判断内容，必须用 git show 查看实际变更：

git show abc1234 —— 显示提交信息 + diff，确认是不是你删掉的功能或修复
git show abc1234 --name-only —— 只看改了哪些文件，适合快速筛选
git log -1 --oneline abc1234 —— 看精简摘要，比 git show 更快

如果提交量大，建议先用 git fsck --lost-found | grep "dangling commit" | head -20 抽样检查前 20 个，避免逐个试错。

别指望 git fsck 自动分类或打标签——它只负责“挖坟”，不负责“认亲”。

alfred-github-backup

GitHub 仓库备份技能 - 将 OpenClaw 工作空间自动或手动备份至 GitHub 私有仓库。支持自动定时备份和手动交互式配置，引导完成 Token 配置、仓库创建、首次备份及定时任务设置。用途：(1) 首次设置 (2) 日常备份。

下载

找回后如何安全挂载到分支上？

确认好目标 commit 后，最稳妥的方式是新建分支指向它：

git branch recover-branch abc1234 —— 创建本地分支，不切换，安全可控
git checkout recover-branch —— 切过去验证代码是否完整
如果要推送到远程：git push origin recover-branch

不要直接 git reset --hard abc1234 到当前分支——万一搞错 commit，会再次丢失当前 HEAD 的历史。

特别注意：如果该 commit 依赖其他 dangling blob/tree（比如它改的某个文件在 dangling blob 里），git show 仍能正常显示，但 checkout 后文件可能缺失。这时需要 git fsck --lost-found 同时抓出相关 blob，并用 git cat-file -p <blob-hash></blob-hash> 手动恢复内容。