You see the Git documentation saying things like
The branch must be fully merged in HEAD.
But what is Git HEAD exactly?
You see the Git documentation saying things like
The branch must be fully merged in HEAD.
But what is Git HEAD exactly?
You can think of the HEAD as the "current branch". When you switch branches with git checkout, the HEAD revision changes to point to the tip of the new branch.
You can see what HEAD points to by doing:
cat .git/HEAD In my case, the output is:
$ cat .git/HEAD ref: refs/heads/master It is possible for HEAD to refer to a specific revision that is not associated with a branch name. This situation is called a detached HEAD.
To quote other people:
A head is simply a reference to a commit object. Each head has a name (branch name or tag name, etc). By default, there is a head in every repository called master. A repository can contain any number of heads. At any given time, one head is selected as the “current head.” This head is aliased to HEAD, always in capitals".
Note this difference: a “head” (lowercase) refers to any one of the named heads in the repository; “HEAD” (uppercase) refers exclusively to the currently active head. This distinction is used frequently in Git documentation.
Another good source that quickly covers the inner workings of git (and therefor a better understanding of heads/HEAD) can be found here. References (ref:) or heads or branches can be considered like post-it notes stuck onto commits in the commit history. Usually they point to the tip of series of commits, but they can be moved around with git checkout or git revert etc.
I recommend this definition from github developer Scott Chacon [video reference]:
Head is your current branch. It is a symbolic reference. It is a reference to a branch. You always have HEAD, but HEAD will be pointing to one of these other pointers, to one of the branches that you're on. It is the parent of your next commit. It is what should be what was last checked-out into your working directory... This is the last known state of what your working directory was.
The whole video will give a fair introduction to the whole git system so I also recommend you to watch it all if have the time to.
What happens if you create a new branch? Well, doing so creates a new pointer for you to move around. Let’s say you create a new branch called testing. You do this with the git branch command: $ git branch testing
This creates a new pointer at the same commit you’re currently on
How does Git know what branch you’re currently on? It keeps a special pointer called HEAD. Note that this is a lot different than the concept of HEAD in other VCSs you may be used to, such as Subversion or CVS. In Git, this is a pointer to the local branch you’re currently on. In this case, you’re still on master. The git branch command only created a new branch ― it didn’t switch to that branch
HEAD file pointing to the branch you’re on.
Assuming it is not a special case called "detached HEAD", then, as stated in the O'Reilly Git book, 2nd edtion, p.69, HEAD means:
HEADalways refers to the most recent commit on the current branch. When you change branches,HEADis updated to refer to the new branch’s latest commit.
so
HEADis the "tip" of the current branch.
Note that we can use HEAD to refer to the most recent commit, and use HEAD~ as the commit before the tip, and HEAD~~ or HEAD~2 as the commit even earlier, and so forth.
HEAD refers to the current commit that your working copy points to, i.e. the commit you currently have checked-out. From the official Linux Kernel documentation on specifying Git revisions:
HEADnames the commit on which you based the changes in the working tree.
Note, however, that in the upcoming version 1.8.4 of Git, @ can also be used as a shorthand for HEAD, as noted by Git contributor Junio C Hamano in his Git Blame blog:
Instead of typing "HEAD", you can say "@" instead, e.g. "git log @".
Stack Overflow user VonC also found some interesting information on why @ was chosen as a shorthand in his answer to another question.
Also of interest, in some environments it's not necessary to capitalize HEAD, specifically in operating systems that use case-insensitive file systems, specifically Windows and OS X.
Take a look at Creating and playing with branches
HEAD is actually a file whose contents determines where the HEAD variable refers:
$ cat .git/HEAD ref: refs/heads/master $ cat .git/refs/heads/master 35ede5c916f88d8ba5a9dd6afd69fcaf773f70ed In this repository, the contents of the HEAD file refers to a second file named refs/heads/master. The file refs/heads/master contains the hash of the most recent commit on the master branch.
The result is HEAD points to the master branch commit from the .git/refs/heads/master file.
I'd just like to detail a few things in Greg Hewgil's accepted answer. According to the Git Pocket Guide
Branch:
the branch itself is defined as all points reachable in the commit graph from the named commit (the “tip” of the branch).
HEAD: A special type of Ref
The special ref HEAD determines what branch you are on...
Refs
Git defines two kinds of references, or named pointers, which it calls “refs”:
- A simple ref, which points directly to an object ID (usually a commit or tag)
- A symbolic ref (or symref), which points to another ref (either simple or symbolic)
As Greg mentioned, HEAD can be in a "detached state". So HEAD can be either a simple ref (for a detached HEAD) or a symref.
if HEAD is a symbolic ref for an existing branch, then you are “on” that branch. If, on the other hand, HEAD is a simple ref directly naming a commit by its SHA-1 ID, then you are not “on” any branch, but rather in “detached HEAD” mode, which happens when you check out some earlier commit to examine.
I think 'HEAD' is current check out commit. In other words 'HEAD' points to the commit that is currently checked out.
If you have just cloned and not checked out I don't know what it points to, probably some invalid location.
A great way to drive home the point made in the correct answers is to run git reflog HEAD, you get a history of all of the places HEAD has pointed.
After reading all of the previous answers, I still wanted more clarity. This blog at the official git website http://git-scm.com/blog gave me what I was looking for:
The HEAD in Git is the pointer to the current branch reference, which is in turn a pointer to the last commit you made or the last commit that was checked out into your working directory. That also means it will be the parent of the next commit you do. It's generally simplest to think of it as HEAD is the snapshot of your last commit.
Head points to the tip of the currently checked out branch.
In your repository, there is a .git folder. Open the file in this location: .git\refs\heads. The (sha-1 hash) code in that file (master in most cases) will be the most recent commit, i.e the one seen in the output of the command git log. More info on the .git folder: http://gitready.com/advanced/2009/03/23/whats-inside-your-git-directory.html
These two may confusing you:
head
Pointing to named references a branch recently submitted. Unless you use the package reference , heads typically stored in $ GIT_DIR/refs/heads/.
HEAD
Current branch, or your working tree is usually generated from the tree HEAD is pointing to. HEAD must point to a head, except you are using a detached HEAD.
Take a look at http://git-scm.com/book/en/Git-Branching-What-a-Branch-Is
Figure 3-5. HEAD file pointing to the branch you’re on.
As a concept, the head is the latest revision in a branch. If you have more than one head per named branch you probably created it when doing local commits without merging, effectively creating an unnamed branch.
To have a "clean" repository, you should have one head per named branch and always merge to a named branch after you worked locally.
This is also true for Mercurial.