这听起来像是你试图使用一个与git工作方式不太匹配的工作流程。
首先，git中的“detached head”与Mercurial中的“head”概念不一样。Git只有一个HEAD，也就是当前 checkout 的提交。“Detached”只是意味着当前没有 checkout 的分支。所以当你创建一个提交时，它不会与分支关联，当你 checkout 一个不同的提交时，它会丢失。
在Git中，你关心的每一个提交都应该可以从某个分支中访问。没有所谓的“匿名分支”，这就是为什么git在提交到一个分离头上时会警告你。在一个分离头上提交就像分配一个对象，然后扔掉指针;这是可能的，但几乎从来没有你想做的。记住，git中的分支是轻量级的，并且可以是短暂的。只需在提交之前创建一个分支，这样你就可以再次找到你的提交。
话虽如此，如果你真的想看到你的仓库的结构，包括只从reflog引用的提交，你可以使用用途：

git log --graph --decorate $(git rev-list -g --all)

字符串

你想要git fsck --lost-found
它会给你给予悬空提交（不是在分支上）。
输出结果如下所示：

Checking object directories: 100% (256/256), done.
dangling blob 18bcff3c8741a2cf2522f29e90570efec46b32a6
dangling blob 98ea60e43e9ec74b5e4a6b9bee774fc39be2feed
dangling blob bdd4824eb73f39327afd191fb704a0380963384a
dangling blob 45a99326deead9d436ff6b54d7e40b3d8b16c4b2
dangling commit 488bc730f09ceba206331660ecb1f9156f5ae594
dangling commit d3c35fc70085c3c25b916073554ab631bdb8b11c
dangling commit ee99e7a0e2fe2e34a68a19ca76f623274edc2ab6

字符串
然后，使用git show获取更多信息--例如：git show d3c3
你也可以得到关于“blob”的信息，这可能是合并冲突中的一个阶段性更改，但从未提交。有助于恢复丢失的数据。
顺便说一句，上面使用git log的答案也很棒。

考虑使用Jujutsu或Sapling等替代工具，这两种工具都是以匿名的head为中心的工作流。这两种工具都可以与Git repos一起使用，尽管只有Zetsu可以拥有一个“托管的Git repo”，这使得它可以在大部分时间使用以Git为中心的工具。
（我过去是Sapling的主要贡献者，尽管我现在更喜欢并全职使用Yuttsu。