问题描述
我有一个独立的HEAD，想找出原因.
I have a detached HEAD and would like to find out why.
我做了git status，它在许多其他输出中给出了HEAD detached at 37f091b，所以我忽略了它并提交了git commit.然后我又做了git status，目的是让自己好看的nothing to commit, working directory clean取悦我，但是不得不看一个难看的HEAD detached from 37f091b.
I did git status which gave a HEAD detached at 37f091b amongst a lot of other output, so I overlooked it and committed, git commit. Then I did git status again with the intention to please myself with a nice nothing to commit, working directory clean but had to see an ugly HEAD detached from 37f091b.
现在我不明白HEAD detached at 37f091b最初是从哪里来的. A git log --decorate显示
Now I don't understand where the HEAD detached at 37f091b came from at the first place. A git log --decorate shows
ffb3802 (HEAD)
37f091b (origin/master, origin/HEAD, master)
62220f1
在我看来，37f091b是我的主分支，并且在提交之前不应该分离HEAD，现在我应该有一个简单的线性历史记录，也没有分离的头?如何诊断出问题了?
To me that seems like 37f091b is my master branch and HEAD should not have been detached before the commit and now I should have a simple linear history with no detached head either? How can I diagnose what went wrong?
(查看相关问题，我还要注意:git stash list没有显示输出.我能够通过git branch fix_detached_head ffb3802，git merge fix_detached_head和git branch -d fix_detached_head摆脱整个问题.所以我的问题是能以某种方式找出我如何陷入困境吗?如果在我提交ffb3802时37f091b与master分离，那似乎表明master分支一定不在37f091b处，但是在哪里?)
(Looking at related questions I want to also note: git stash list shows no output. I was able to get rid of the whole thing by git branch fix_detached_head ffb3802, git merge fix_detached_head and git branch -d fix_detached_head. So my question is if I can somehow find out how I got myself even into this mess? If 37f091b was detached from master when I committed ffb3802, that seems to indicate that the master branch must not have been at 37f091b, but where then?)
推荐答案
这里有两件事在起作用.
There's a couple of things at play here.
"HEAD"是一个神奇的指针，它告诉git您上次为索引检出的内容，通常是工作文件夹.
"HEAD" is a magical pointer that tells git what you last checked out for your index, and usually, your working folder.
HEAD是一个指针，它可以直接指向提交(在这种情况下HEAD包含提交的SHA1 ID)或分支(在这种情况下HEAD包含分支的名称).
HEAD is a pointer, and it can either point directly at a commit (in which case HEAD is containing the SHA1 id of the commit) or a branch (in which case HEAD contains the name of the branch).
如果您最终处于分离的HEAD"状态，则表示HEAD 不是指向分支，而是直接指向提交.
If you end up in a "detached HEAD" state it means HEAD is not pointing to a branch, but directly at a commit.
如果在这种状态下进行提交，则将进行提交，将HEAD移至引用您的新提交，并且您的新提交将包含指向HEAD所指向的先前提交的父指针.
If you, in this state, make a commit, the commit will be made, HEAD will be moved to refer to your new commit, and your new commit will contain a parent pointer back to the previous commit that HEAD was referring to.
另一方面，如果HEAD指向一个分支，并且您执行了上述操作，然后进行提交，则上面的所有操作仍然会发生，但是分支也会随之移动.分支和 HEAD现在将指向此新提交.
If, on the other hand, HEAD is pointing to a branch, and you do the above, make a commit, then everything above still happens, but the branch is also moved with it. The branch, and HEAD, will now point to this new commit.
也没有什么可以阻止HEAD指向分支顶端的同一提交.
There is also nothing that prevents HEAD to point to the same commit that is at the tip of a branch.
因此，有了以上所有信息，这就是您的情况.
So with all the above information, here's what happened in your case.
由于某种原因，您设法检出了master指向的提交，而不是检出了master.
For some reason you managed to check out the commit that master points to, instead of checking out master.
您的历史记录如下:
master
v
*---*---*---*
^
HEAD
然后您进行了提交，这使您的历史记录如下:
Then you made a commit, which makes your history look like this:
master
v
*---*---*---*---*
^
HEAD
反之，如果您已签出master，则这是您上次提交之前要去的地方:
If, on the other hand, you had checked out master, this is where you would've been before your last commit:
HEAD
v
master
v
*---*---*---*
如果您现在进行了提交:
And if you now did a commit:
HEAD
v
master
v
*---*---*---*---*
所以剩下唯一需要回答的神秘问题是，您如何最终直接签出提交，而不是签出分支.
So the only mysterious part left to answer is how you ended up checking out a commit directly, instead of checking out a branch.
您可以使用各种结帐命令来执行此操作:
You can do this using various checkout commands:
git checkout "HEAD^" # I use quotes because I'm on Windows
git checkout 219874982739827982798723498 # SHA1 id of commit
git bisect ... # it will also check out commits directly
这篇关于在Git中诊断一个模糊的独立HEAD的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！