Git Reset HEAD
Git HEAD is an important concept. In this guide you will learn everything about Git HEAD, Git detached HEAD, and how to fix it.
Join the DZone community and get the full member experience.
Join For FreeRecently, I published a detailed guide about Git reset HEAD. In case you need a downloadable pdf copy, you can get it here.
In this Git HEAD guide, I will explain all about the basics. You will learn about the detached head and how you can reset it with a few simple git commands.
Git HEAD Basics
Git branches are super helpful, and you can create a new branch, merge a branch, or delete a branch, per your requirements. There are many git commands that you can use to manage your branches in git.
When you use the git checkout branch, HEAD points out the last commit. In simple terms, you can say Git HEAD is the current branch. Whenever you check out a branch or create a new branch, Git HEAD transfers it.
HEAD is a reference to the last commit in the current check-out branch.
In the repository, HEAD points to the starting point of the current branch at all times. In other words, the HEAD is a pointer to the parent of the next commit or where the next commit will occur since it is where the repo left off.
More specifically, HEAD is a moving pointer that may or may not refer to the current branch, but it always refers to the current commit.
What Is Git HEAD^?
The Caret (^) is the parent of the Commit.
What Is HEAD~?
The tilde (~) is a shorthand character for a row of several characters (^).
The equivalence of HEAD~2 to HEAD^^.
And, in the same way, the equivalence of HEAD~3 to HEAD^^^.
The default used is 1, if no number is mentioned, so HEAD~ is equal to HEAD^.
How You Can Check the Status of HEAD?
You can see where the current Git HEAD is pointing to with the following command:
- cat .git/HEAD
In my case, it’s pointing to the main branch, so the following output will appear on the shell:
- $ cat .git/HEAD
- ref: refs/heads/main
And, if you are interested in the commit hash Id on which head is pointing, you can use the following command to display it:
- git rev-parse --short HEAD
HEAD vs Head
The HEAD is the branch (or a commit) you are now looking at.
Note: to signify this status, we have used all capital letters.
In lowercase, you can see "head" printed. It may refer to all of the "heads" in a repository while "head" is written in lowercase. For example, "main" is a "head" since a branch is a reference to it.
There could be a variety of heads in a repository, but just one HEAD.
Maybe this sounds complicated. Let's sum up HEAD vs. head in a phrase: HEAD in all caps is a reference or commit that you are accessing in your repository, while a "head" without caps is “head” that you are not viewing.
Git HEAD Advantages
- It is used to refer to the branch recently committed.
- Changes from the last point visited will be used to create changes.
- It may also be used from there to travel to distinct points of history and function.
Git Detached HEAD
The HEAD in Git is the current branch on which you're working on.
When you are trying to checkout a git branch, HEAD points to the top of that branch. And, with that, you can continue to work without any difficulties.
And, if you check out a particular commit, you are already in a detached HEAD state. And, Git will not put the HEAD in the branch. It means any commits made after that won't belong to any git branch. Technically, you can not save any work in your repository.
Having no branch, you could miss all your work completed to fix some problem, as you can not merge your code into a main or with any other git branch.
If you switch branches with the git checkout command at that point, your modifications will be lost.
Detached HEAD Solution
"You're in the 'detached HEAD' state" is not an error message, and there are zero worries.
As I mentioned earlier, this status means that you are no longer in a Git branch.
Whether this status was unintended and you want to "fix" the 'detached HEAD' or not, you can go back to the branch you're supposed to be on by running the git checkout order.
Return to the previous branch from the 'Detached HEAD' state:
- $ git checkout <your-branch>
And in case you forget about the branch you've been on, you should only try out another (any) git branch, and the issue will be fixed.
If you have already made some changes to the 'detached HEAD' and do not want to lose them, you should save these changes to a temporary branch:
- $ git checkout -b <temporary-branch-name>
Later the temporary branch may be merged into another branch, e.g. to the main branch:
- $ git checkout main
- $ git merge <temporary-branch-name>
Working with (or on) a disconnected head is not a concern. This happens when you're working with bisects or if you just want to try out a particular iteration of a previous commit. There's nothing to deter you from working on this unnamed branch, either; you can keep going and devote as much as you want.
Keep in mind, though, that locating a commit depends on what you do with that hash. Usually, you will build a new branch (say, this is a bug patch for a recently released bit of code), or you will end up tagging it with a hotfix identifier. There's still a reflag that you can use to get back to your commit if you end up changing from a disconnected brain.
Git Head Reset
Using git reset-hard HEAD to restore to the previous commit is an issue that falls to developers. Luckily, to correct this, there is a simple solution to follow.
First of all, "git reset -- hard" is a dangerous command. It can destroy all the non-committed modifications. Make sure to double-check that the git status output is empty (clean) before you start using it.
Your changes are secure once you have committed them to the repository. And, when you try to revert those changes using the git reset command, it will make your current branch back to that point.
HEAD reveals the new branch or commit, meaning that what git reset-hard HEAD can do is throw away all the changes you have that are not committed.
The git command "git reset" overwrites (HEAD / Index (also known as a staging area) / working directory) in a particular order:
- Transfer whatever HEAD branch points to.
- To make it look like the Index.
- To make it look like a working directory.
And, there are three different modes of a git reset.
Soft:
This git command will only move the HEAD. And, your Index (staging area) and working directory will not be affected.
And, here is the git command which you use to reset the HEAD:
- $ git reset --soft
Mixed:
This is the default option. So if you write git reset, the command will run in the mixed model.
This git command will move the HEAD and also update the staging area. So this command will undo content added by git add and by git commit.
And the syntax to use the git reset mixed command is as follows:
- $ git reset --mixed or $ git reset
Hard:
This command can be dangerous to use. Only use if you know what exactly you are doing.
This command will move the HEAD and the staging area. Also, it will undo your last commit.
If you want to reset the commit right before HEAD (you need to undo your last commit), you can use the git reset command with the hard option:
- git reset --hard HEAD^
Bonus: In case you need a downloadable pdf copy on Git Best Practices or Git HEAD (with easy-to-understand examples and with Git commands) you can get it from here.
Conclusion
The aim of the command "git reset" is to transfer the current HEAD to the stated commit (on the HEAD itself, one commit before HEAD, and so on).
And, you can use the "-hard" option to reset the index (or staging area) and working directory files. You will be left with the untracked files from your working directory using "-hard."
Opinions expressed by DZone contributors are their own.
Comments