
When you make a new commit on a branch or pull commits from a remote, the head file for that branch is always updated to reflect the commit ID of the tip of the branch. In this path you will find one file for each branch, and the content in each file will be the commit ID of the tip (most recent commit) of that branch.įor example, there is literally a file called master in that path that contains the commit ID of the tip of the master branch. You can view your repository’s heads in the path.

In Git, a head is a ref that points to the tip (latest commit) of a branch. Refs are stored in a special hidden location in your Git repository at the path. When representing a branch name, a ref such as master represents the tip (most recent commit ID) on that branch. The commit ID that a ref points to is dynamic so it can change over time. You can think of each of these as a variable name that points to a commit ID. Another example of refs are Git tags such as v0.1 or v0.2. Examples of refs are Git branch names such as master and dev. A ref is essentially a pointer to a commit. In Git, a ref is a human readable name that references a Git commit ID. Git Refs and Headsīefore jumping right into our main question, it will be useful to provide some background information on two Git concepts, Git refs and Git heads.
GIT COMMIT CHANGES TO NEW BRANCH SOFTWARE
In this article, we will answer the question What is Git HEAD? After you learn Git HEAD, you will have added to your knowledge and understanding of Git's version control capabilities and increased your confidence as a software developer. However, this seemingly complex feature is actually simple and helpful. You may have even run into issues with a Git detached HEAD a few times. If you have used Git to work on a project before, you have likely noticed the term HEAD appear in response to commits, checkouts, and pulls. Fixing Detached HEAD in Git by Creating a New Branch.

Fixing Detached HEAD in Git by Switching Branches.
