首页 > 解决方案 > 恢复丢失的提交到分离的头部

问题描述

标签: gitversion-control

解决方案


Run git reflog to get Git to spill out the contents of the HEAD reflog. This will get you commit hash IDs (on the left), numbered @{...} suffixed names (next to the hash IDs), and information about what made that the commit that HEAD identified (for commits, that's commit subject lines).

If one of the subject lines looks promising, try that commit hash ID: e.g., git show hash. If that's the commit you're looking for, you've found it: make a branch name for it. If not, keep going with the reflogs. To make a new branch name newname that points to a given commit hash hash, use git branch newname hash.

Given that you have some data you can search for (or a blob hash ID like 9dc18eb8bba4d381ad0a96c782fec57928dc92d2—see the output of git show 9dc18eb8bba4d381ad0a96c782fec57928dc92d2 to see if that's a file of interest, for instance) you can also search the commits in the reflog to see if any of them have, in their snapshots, a file with that blob hash ID. That's usually less effective than the quick "look at the top few reflog entries" method, but note that git ls-tree -r hash | grep 9dc18eb8bba4d381ad0a96c782fec57928dc92d2 is a way to find out whether the given commit hash ID hash refers to that version of the file.

Side note: the answer you linked referred to someone who was in the middle of a git rebase when they did stuff on their detached-HEAD setup, and then lost it; the commands you quoted are useful after you've set up a branch name to be able to find the commits.


推荐阅读