Detached head git как исправить

A common source of confusion when using Git is not knowing what it all means when you see an output like this:

You are in 'detached HEAD' state. You can look around, make 
experimental changes and commit them, and you can discard any 
commits you make in thisstate without impacting any branches 
by switching back to a branch.

What does it all mean?

To really understand what is happening, we need to look inside Git.

Git commits are immutable—meaning you can create new ones, but what’s already inside will never be changed. This is how our repository keeps data safe for us. The only way of making changes to the repository is by creating new commits.

Git commits gives us a stable, complete history of the changes to the repository. On top of this stable base, we have a dynamic part: branches. What can be surprising at first is that branches are just labels. They are pointing to one commit. They literally have no other data than the name and its position.

Anything besides that—for example,

• special meaning of main or master,
• patterns such as feature/<info>, or <branch-owner>/<description>
  —is just a convention the teams are using. From Git’s point of view, your main or master branch is no different than lorem-ipsum.

Current commit

HEAD is a pointer to the current commit—the place where you are in the repository right now. It is used as:

• a reference point when you want to see the last changes to your working copy with git diff
• a commit that will be used as a parent when you create a new commit

Your HEAD is a central piece of the state of your repository.

Normal state

The typical workflow with Git is as follows:

• you are on some branch,
• you create new commit, and
• Git moves your branch to this new commit.

If you limit yourself to checking branches only, you will never leave this state. When you run git status, it tells you what branch you are on:

$ git status
On branch main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean

Detached HEAD

So far, HEAD (current commit) and branch were in a normal, aligned state. Things get complicated when you check out something that is not a branch—for example, when you switch to a commit by its ID:

$ git checkout abc01e7

where abc01e7 is an ID of any commit in the repository—it can be inside of any of the branches, on top of one of them, or in another place of the repository history.

Because you are not on a branch anymore, the git status changes to:

$ git status
HEAD detached at abc01e7
nothing to commit, working tree clean

To call your attention to this situation, Git colors HEAD detached to red.

Why would you switch to commit instead of branch?

Because you can, and it can be sometimes useful. A common scenario is to see how the application worked a few commits earlier—for example, for troubleshooting. We noticed something wrong, such as a feature not working as expected, and we check out the last commit that we expect to work OK. In this way, we can pinpoint when exactly the issue was introduced.

How does it impact the work?

Because you are not on a branch, Git doesn’t have a branch to update when you create a new commit. So all the commits you a create there are stored but are left dangling: there is no way to easily reach them, and, as such, they are assumed to be unimportant. At some point, the garbage collector will remove them permanently from the repository.

How did it happen?

You left the branch and moved your HEAD elsewhere. It could happen:

• by checkout of non-branch reference:
  • git checkout <commit ID>—as above
  • git checkout HEAD^—the last commit
  • git checkout <tag>—tags are similar to branches, but they are meant to be immutable and are not updated as branches
• while your git rebase stopped halfway—due to conflict or to let you make changes to the commits,
• during git bisect

How to fix it

Luckily, you get a bit of instruction directly in the CLI when you check out non-branch reference:

$ git checkout abc01e7
Note: switching to 'abc01e7'.

You are in 'detached HEAD' state. You can look around, make 
experimental changes and commit them, and you can discard any 
commits you make in this state without impacting any branches 
by switching back to a branch.

If you want to create a new branch to retain commits you 
create, you may do so (now or later) by using -c with the 
switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable 
advice.detachedHead to false

Create a new branch

You can create a new branch, exactly in the point where you are—including all the commits that you maybe created from there. You can create the branch with the following syntax:

git switch -c <new-branch-name>

or the command form Git versions older then 2.23:

git checkout -b <new-branch-name>

Those commands create a new branch, and set it as your current branch.

Alternatively, you can just create a new branch on you current commit and stay in the detached HEAD state:

git branch <new-branch-name>

Switch to a branch and merge your commits

Alternatively, you can pick an existing branch and either merge your dangling commits or cherry-pick them. If you are not sure what those terms mean, then stick to creating a new branch, because it will allow you to do the same things, but in a less confusing setup.

How does it look in the tools

Besides the git status, how can you see this state?

You can see it on your Git tree graph

If you use git log --oneline --graph --decorate --all (something I recommend to define as a git tree alias) it will show your HEAD differently. When it’s on branch, the output looks like this:

$ git tree
* abc01e7 (HEAD -> main, origin/main) Add lorem ipsum to readme
* edd3504 Add readme

The HEAD points to the branch you are on with an arrow. When you are in “detached HEAD” state, main and HEAD are displayed separately, as an unrelated reference:

$ git tree
* abc01e7 (HEAD, origin/main, main) Add lorem ipsum to readme
* edd3504 Add readme

The difference is subtle but obvious when you know why you should pay attention to it.

GitHub desktop

At main branch:

“Detached head” state:

Can you see the difference in the middle part of the header? One is showing “Current branch”; while the other “Detached HEAD”.

Source tree

At main branch:

“Detached head” state:

It shows as the current branch HEAD.

Want to learn more?

Git has many confusing parts when you start using it, but it gets way simpler once you understand better the way it stores its data. If you are interested in learning more about Git, sign up here to get updates about my Git-focused content.

If you are one of the millions of developers who use Git, you may have come across the “detached HEAD state”. It is a strange phrase, but it’s not as alarming as it might sound. Here’s what it means. In Git, HEAD refers to the currently checked-out branch’s latest commit. However, in a detached HEAD state, the HEAD does not point to any branch, but instead points to a specific commit or the remote repository. If you want to keep the changes you made while in the detached HEAD state, you can solve this problem with three simple steps: creating a new branch, committing the changes, and merging the changes.

Git allows developers to maintain a history of changes (commits) to their code. It makes collaboration easier by allowing branching to keep code for different features separate and by seamlessly merging commits from multiple people. You can revert to previous commits in seconds if something goes wrong. It is fast, scalable, and has more commands and flexibility than older version control systems (VCS).

However, learning Git is more complicated than it was with older systems. Complex commands and a less intuitive user interface can sometimes lead to unwanted states, including the detached HEAD state. In this article, we will explore what the Git detached HEAD state is and some situations that cause it. Then, we will demonstrate how to save or discard changes in a detached head so you can quickly recover from the situation.

What is a normal HEAD state

Below is a diagram of the Git HEAD in a normal state, pointing to the latest commit in the main branch.

In this image, the HEAD points to the latest commit and current checked-out branch on every commit in the current branch.

HEAD is also a common state when working with multiple branches.

In this situation, you have two branches, the main branch and a feature branch. Since you are checked out to the feature branch, HEAD points there. You can create this scenario with the following Git commands:

git branch feature
git checkout feature
git commit -m “checked out to feature”
git checkout Main
git commit
git commit -m “Latest commit”
git checkout feature

What does detached HEAD mean?

In Git, the detached HEAD state occurs when the HEAD does not point to a branch, but instead points to a specific commit or the remote repository.

In both of the diagrams in the previous section, HEAD points to the most recent commit in the currently checked out branch, which is its normal state. In Git, you can also check out a particular commit, which results in the detached HEAD state. Continuing from the previous scenario, if you check out to the first commit on the main branch, you will see that HEAD is now detached.

In this case, HEAD does not point to any branch—it references a commit.

Scenarios that can cause a detached HEAD state

You can find yourself in a detached HEAD state primarily through two scenarios:

1. Checking out a specific Secure Hash Algorithm 1 (SHA-1) commit hash
2. Checking out to a remote branch without fetching it first

We already demonstrated that if you check out the SHA-1 commit hash, you will be in the detached HEAD state. Another situation that causes a detached HEAD is checking out the remote branch. If you check out to the origin (main) branch, which is read-only, you will be in the detached HEAD state.

Some other scenarios can cause a detached HEAD as well. For example, checking out to a specific tag name or adding ^0 on any given branch causes the detached HEAD state.

How to save changes in a detached HEAD

If you find yourself a detached HEAD state and realize it quickly, you can quickly recover by checking out the previous branch. But what if you are in the detached HEAD state by mistake then perform commits over commits? If you are committing in the detached HEAD state, does that mean your changes are not saved?

Not at all. It just means you are not currently attached to any branch, and as a result, your HEAD is detached. To keep the changes made while in the detached HEAD state, use these three steps:

• Create a new branch
• Commit the changes
• Merge the changes

Create a new branch

To save changes committed in a detached HEAD state, you first need to create a new branch.

Continuing from the scenario described above, you create a new branch called temp-branch. As soon as you make the branch and check out to it, the HEAD is no longer detached.

Commit the changes

After checking out to the new branch, you can commit the changes, which Git will preserve.

Merge the changes

Now, you check out to the branch where you want the changes. In this case, you want to merge the changes to the main branch. So, you first need to check out the main branch, then merge the changes from temp-branch and add the final commit message.

With these simple steps, you have successfully preserved your changes and recovered from the Git detached HEAD state.

How to discard changes in a detached HEAD

If you want to discard the changes in the detached HEAD state, you only need to check out to the existing or previous branch. The commits on the detached HEAD state will not affect your existing branch, and Git will archive them.

The diagram below shows a situation in which, after going into the detached HEAD state, you make two commits that you do not want to keep. Then, you check out to the main branch. The dotted circles indicate that these commits are no longer part of any branch, and Git will delete them.

Note that once Git prunes your detached HEAD state commits, there is no way to get them back. However, if they have not been deleted, you can check out to that SHA-1 commit hash, create a branch, and merge it to the desired branch to preserve the changes.

Conclusion

Git is a valuable developer tool and more popular than older versioning tools such as CVS and Subversion. That said, it can be more complex and challenging to master, and can sometimes lead to confusing situations such as the detached HEAD state.

If you find yourself in the detached HEAD state, remember that you can always preserve your changes by creating and checking out to a new branch, then committing and merging the changes in the desired branch. If you do not want to save the changes, you can simply check out to any branch, and Git removes those commits.

Also, Git 2.23 has a new command, git switch. This is not a new feature but an alternative command to git checkout so you can switch between the branches and create a new branch. To change from one branch to another, use git switch branchName to create a new branch, then switch to it using the git switch -c branchName command.

Although finding your code in the detached HEAD state is not ideal, you can use these methods to move or remove your commits and quickly get your project back on track.