State without impacting any branches by switching back to a branch. You can look around, make experimentalĬhanges and commit them, and you can discard any commits you make in this However, after running the below command the repo is in a detached HEAD: $ git checkout 5282c7c All of that means, in the above scenarios, HEAD is synonymous with “the last commit in the current branch.” This is the normal state in which HEAD is attached to a branch:Īs we can see, HEAD points to the master branch, which points to the last commit. When we change branches, HEAD is updated to point to the branch we've switched to. When we add a new commit, our branch reference is updated to point to it, but HEAD remains the same. As long as you do that before returning to your regular branch, you’ll be fine.Īnd there you have it! Once you understand the underlying logic in play, the detached HEAD is not so scary and can be quite useful.For most of the time, HEAD points to a branch name. Once you do that, you can commit and push your code to the new branch. Here are the Git commands to do so: git branch If you have some code changes you don’t want to lose, create a new branch and commit your code. Create a new branch and commit your code. Git will discard your uncommitted code, and your HEAD will point to a branch again. If you found yourself in this state by accident or finished experimenting, all you need to do is check out another branch. With that said, there are two ways to make things go back to “normal.” Check out a different branch Remember, a detached HEAD is not an error but a feature in Git. Since the state is simple to correct, that’s a great way to play around with your code. In that case, rolling back to a certain moment can be helpful.Īnother reason is to experiment with alternative solutions to any given problem. There are a couple of reasons to check out a specific commit. As a side-note, you can get hashes of your commits using git log: It happens when you run the checkout command using a commit hash rather than a branch name. Instead, it’s pointing to a specific commit. To reiterate, it means that the HEAD of your project is not pointing to a branch anymore. So what is a detached HEAD? According to Tower’s blog post: “When a specific commit is checked out instead of a branch – is what’s called a “detached HEAD.” Notice how both master branch and HEAD point to the same commit. And when you run a checkout command with a branch name, Git checks out the latest commit the branch points to.įollowing that logic, when HEAD points to a branch, it points to the latest commit under that branch. When you push to a branch, that label now points to the new commit. Simply put branches are labels for commits. But let’s try to come up with a simple definition. Git branchĪ lot of people have a general idea of what branch is. It also defines the current state of your project. The next question then is what is HEAD? HEAD is a pointer to your current working commit. Notice how each commits points to the previous one, except for the first commit. Here’s a diagram to illustrate this point: Each commit points to a previous commit as its parent. Commits are connected through the parent-child relationship. Git is a system made of objects and pointers. Don’t worry we’ll only cover enough to understand the root cause of the state. Basics of Gitįirst, let’s skim over how Git works. If you would like to know more about the reasoning behind the state, then read along. If you’re here for the solution, feel free to skip to the “How to fix” section. But let me put your worries at ease – the detached HEAD state is easily reversible and is a natural state of a project. I wish the creators of Git picked a less alarming one. I agree, the You are in 'detached' HEAD state message does sound scary.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |