当我开始使用git时，这对我来说是一件令人困惑的事情，后来我明白了为什么会发生这种情况，以及处理这种情况的最佳方法是什么。

出现这种情况的根本原因是，通常gitHEAD总是指向某个分支，当您试图将HEAD指向某个特定的提交时，就会将HEAD置于分离的HEAD状态。

HEAD连接时的状态-

cat .git/HEAD     # output--> ref: refs/heads/master or ref: refs/heads/main

当HEAD处于分离状态时-

cat .git/HEAD     # output--> b96660a90cad75867453ebe1b8d11754bbb68b0e <commit hash>

解决方案-

git stash           # Temporarily shelves (or stashes) changes
git branch          # Find your default branch
git switch master   # Point HEAD to master or main branch
git stash pop       # Apply all the changes you had previously

当您处于分离头部的情况并创建了新文件时，首先确保将这些新文件添加到索引中，例如：

git add .

但是，如果您只更改或删除了现有文件，则可以通过以下方式同时添加（-a）和提交消息（-m）：

git commit -a -m "my adjustment message"

然后，您可以简单地使用当前状态创建一个新分支：

git checkout -b new_branch_name

你将有一个新的分支，所有的调整都将在新分支中。然后，您可以根据需要继续推送到远程和/或签出/拉入/合并。

当您在git中签出一个特定的提交时，您将处于分离的头部状态。。。也就是说，您的工作副本不再反映命名引用的状态（如“master”）。这对于检查存储库的过去状态非常有用，但如果您确实试图恢复更改，则不需要检查。

如果您对特定文件进行了更改，并且只想放弃这些更改，则可以使用如下签出命令：

git checkout myfile

这将丢弃所有未提交的更改，并将文件恢复到当前分支头部的任何状态。如果要放弃已提交的更改，可以使用reset命令。例如，这将将存储库重置为上一次提交的状态，并放弃任何后续更改：

git reset --hard HEAD^

但是，如果您与其他人共享存储库，git重置可能会造成中断（因为它会擦除存储库历史的一部分）。如果您已经与其他人共享了更改，您通常希望查看git-restore，它会生成一个“反提交”，也就是说，它会创建一个新的提交来“撤消”所涉及的更改。

GitBook有更多细节。

分离的头部意味着您不再在分支上，您已经在历史中签出了一个提交（在本例中，提交是head之前的提交，即head^）。

如果要删除与分离的HEAD关联的更改

你只需要检查你所在的分行，例如。

git checkout master

下次更改文件并希望将其恢复到索引中的状态时，不要先删除该文件，只需执行以下操作

git checkout -- path/to/foo

这将把文件foo恢复到索引中的状态。

如果您希望将更改与分离的HEAD保持关联

运行gitbranchtmp-这将在名为tmp的新分支中保存更改。运行git签出主机如果您想将所做的更改合并到master中，请从master分支运行gitmergetmp。运行git checkout master后，您应该在master分支上。

通常HEAD指向分支。当它不是指向分支，而是指向像69e51这样的提交散列时，这意味着你有一个分离的HEAD。你需要指出两个分支来解决这个问题。你可以做两件事来解决它。

git checkout other_branch//当您需要提交哈希中的代码时不可能创建一个新分支，并将提交哈希指向新创建的分支。

HEAD必须指向分支，而不是提交哈希是黄金法则。

分离的头意味着你没有正确地签出你的分支，或者你刚刚签出了一个提交。

如果您遇到这样的问题，请首先隐藏本地更改，这样您就不会丢失更改。

之后。。。使用以下命令签出所需的分支：

假设您想要分支MyOriginalBranch：

git checkout-b someName origin/MyOriginalBranch