In this Git HEAD guide, I will explain all about 3 important concepts.
First what actually is Git HEAD, what is git detached head, and finally how you can fix the Git detached HEAD issue.
Also in this complete post, as a bonus, I will share all my time Git best practices for Small Teams.
So let’s start.
Git branches are super helpful. And you can create a new branch, merge or delete a branch as per your requirements. There are many git commands which you can use to manage your branches in git.
When you use the git checkout branch, HEAD points out at the last commit. In more simple words you can say Git HEAD is the current branch. Whenever you check out a branch or create a new branch, Git HEAD transferred.
HEAD is a reference to the last commit in the currently check-out branch.
Check the status of HEAD
You can see where the current Git HEAD is pointing to with the following command.
In my case, it’s pointing to the main branch, so the following output will appear on the shell.
$ cat .git/HEAD
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
Detached HEAD Problem
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,’ 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>
Git Best Practices for Team
Source control is the tool every developer need and it is a best friend of a developer. In this distributed environment, the ability to share code with multiple developers, monitor changes, and quickly roll back when problems occur is invaluable.
And there are many Git best practices for small teams, but here I will share my all-time favorite AFTER technique.
So the AFTER technique says
A – Atomic Commits
Atomic commit is important and it has many advantages. The key things to remember when you make atomic commits are –
- Commit any work as a separate charge.
- Commit only when a block of work is done.
F – Frequent Commits
The philosophy behind committing sometimes is to produce a live stream of improvements for yourself.
I’ll do a check-in whenever I have anything that works (meaning, does not break something for someone else).
T – Test your changes before you push them
Checking your code teaches you how to write good code. You learn different ways to solve problems as you have to go through and fix your own bugs.
It’s immeasurable how many ways you can crack code and that’s what makes it so fascinating.
E – Enforce Standards
You should enforce standards so everyone should use them. For example – valuable commit, use of gitignore file, etc.
R – Refactoring is not a feature
The aim of a tech corporation is to sell software that works. Refactoring does not encourage anyone to sell more software unless there is something you need to add to the software that needs refactoring (an extra feature).
So keep in mind that Refactoring is not a feature.
A disconnected HEAD does not mean something is wrong with your repo, as you’ve seen in this article.
Detached HEAD is a less popular condition in which the archive can be stored. It can also be very helpful, apart from not being a mistake, helping you to conduct tests that you can either opt to hold or discard.
Hope you have enjoyed this post on Git HEAD and its best practices.