{"id":3587,"date":"2022-12-05T10:08:15","date_gmt":"2022-12-05T10:08:15","guid":{"rendered":"https:\/\/gitprotect.io\/blog\/?p=3587"},"modified":"2024-12-11T08:43:55","modified_gmt":"2024-12-11T08:43:55","slug":"git-head-git-head-reset-and-git-head-overwrite-what-to-do","status":"publish","type":"post","link":"https:\/\/gitprotect.io\/blog\/git-head-git-head-reset-and-git-head-overwrite-what-to-do\/","title":{"rendered":"Git HEAD – Git HEAD reset and Git HEAD overwrite – what to do?"},"content":{"rendered":"\n

There is a great variety of DevOps tools that serve different purposes and uses. We benefit from them in a number of situations, but sometimes they still can cause some problems. Do you agree with this suggestion, don’t you?<\/p>\n\n\n\n\n\n\n\n

After all, a tool only has certain characteristics and functionalities, but we are the ones who use it in some way or another. We are the ones who decide for which purposes to use a hammer \u2013 to break a window or put a nail into the wall. Let’s not blame the tools, but rather look at ourselves to see if we are using them correctly!<\/p>\n\n\n\n

In the IT world, we use a variety of tools for our daily work, so let’s take this lesson to ourselves. It’s not the tool that can spoil the results of our work, but we are, when we use them in a wrong way. And that’s what this material is about \u2013 how managing Git commands<\/a> we can get rid of the results of our work by carelessly using something called a HEAD.<\/p>\n\n\n\n\n\n

Let’s dive into Git HEAD<\/strong><\/h2>\n\n\n\n

Let\u2019s first briefly discuss what a branch is in Git. How does it work? The ability to branch a project is crucial to modern Version Control Systems. Among other things, Git has gained immense popularity because it allows users to switch between different versions of a project very easily and quickly. This is a vital thing in modern projects.<\/p>\n\n\n\n

The solution to this problem in Git deserves applause. The branch in Git does not track the entire version of the project, but only individual changes. If we change only one file in the project then the others are not saved again. Instead, Git tracks a reference to the previous version. To be even more precise, it is not the branch that holds such information, but the commits. The commits are the ones that contain any new, deleted, or edited files. They are permanent and immutable. Moreover, they create a linear history of the project, so we can roll back to any version of the file from the past.<\/p>\n\n\n\n

And what does a branch have to do with it? This is where the cleverness of this solution reveals itself. Why? Because a branch simply points to a specific commit, for example, the latest commit on the main branch. Thus, the branch itself is just a simple little file, containing the SHA code of a particular commit. Changing of this pointer is very fast, because it doesn\u2019t reload our entire project, but only jumps to another commit. This allows us to add or remove branches according to our desire. We can even have several branches pointing to the same commit! Why not? By the way, it\u2019s quite common.<\/p>\n\n\n\n

Git HEAD<\/h3>\n\n\n\n

And what is the HEAD itself? It\u2019s a special indicator that shows the current master branch by default. The one you are currently on and what version of the project you see on the screen. Though, remember that there is only one HEAD indicator in the whole project!<\/p>\n\n\n\n

So, a Git branch is a pointer to a commit, and HEAD is a pointer to a branch, that\u2019s how we can think of it.<\/p>\n\n\n\n

Displaying HEAD information<\/h2>\n\n\n\n

Well, let’s go further and explain how to check<\/a> what HEAD is pointing to in our project. We can do it in many ways, for example, modern IDEs always mark a branch in a graphical way, in the CLI we can display our Git status and also graphically see where this special indicator is. But there is another way, which does not require our observation skills. We can simply look in the .git<\/em><\/strong> directory in our project and find the file named HEAD <\/em><\/strong>there. Or execute a simple command that will show us its contents:<\/p>\n\n\n\n

cat .git\/HEAD <\/code><\/pre>\n\n\n\n
or<\/p>\n\n\n\n
git rev-parse HEAD<\/code><\/pre>\n\n\n\n
There we will find one line that can tell us which branch (or commit) the HEAD is currently pointing to, for example something like this:<\/p>\n\n\n\n
ref: refs\/heads\/develop<\/code><\/pre>\n\n\n\n
Git reset HEAD <\/h2>\n\n\n\n
Well, we have already cleared out what a branch is, how it works, and what a HEAD is. And what does it give us? Let\u2019s further explain the state we call \u201cdetached HEAD\u201d. In short, it is a state in which our HEAD does not point to any existing branch, but directly to a given commit. This is not a wrong action, sometimes it is expected and we intentionally take such a step. However, we must remember that this leads to a high risk of losing a previous commit or some of them.<\/p>\n\n\n\n
Let\u2019s imagine a situation where, after executing one or more commits, we find that we want to roll back to the previous version and continue working from a new starting point. We can use the Git reset<\/strong> command for this:<\/p>\n\n\n\n
git reset HEAD^<\/code><\/pre>\n\n\n\n
or<\/p>\n\n\n\n
git reset <commit hash><\/code><\/pre>\n\n\n\n
The above command rolls us back one commit backward (HEAD^) or to any indicated commit. This means that our HEAD points to the new location. There are several dangers associated with the Git reset command. The first is that this command allows us to change history, which is not allowed in Git. If we \u201cdelete\u201d a commit already existing in an external git repository, we will not be able to perform a push operation, because of the inconsistency. Never modify an already existing commit history!<\/p>\n\n\n\n
Though, it\u2019s worth remembering that we must be careful with this command. Git reset command can work in 3 different ways: git reset –soft, git reset –mixed, and git reset –hard commands. Using one or another we can delete (or keep) changes from the working directory or staging area.<\/p>\n\n\n\n
Git reset –soft HEAD<\/h3>\n\n\n\n
The purpose of the –soft reset command is to update the reference to a certain commit in the HEAD, where the most recent commit is located on your local system. For example, if you notice that some file to a commit is missing (maybe you forgot to add it), you can use the –soft command:<\/p>\n\n\n\n
git reset --soft HEAD~n<\/code><\/pre>\n\n\n\n
This soft reset command will allow you to move back to the specific commit. Under n, we mean specific reference. For example, if you want to get back to the last commit, you can use git reset –soft HEAD~1.<\/p>\n\n\n\n
git reset --soft <commit ID><\/code><\/pre>\n\n\n\n
With the following command, you can move back to the HEAD with the <commit ID>.<\/p>\n\n\n\n
Git reset –mixed<\/h3>\n\n\n\n
Being a default argument for git reset, git reset –mixed can have two impacts. They are:<\/p>\n\n\n\n