Introduction

HEAD and ORIG_HEAD are both Git references, but they solve different problems. HEAD tells Git where you are now, while ORIG_HEAD is a short-term safety marker Git often writes before operations that may move history in a way you later want to undo.

That difference matters because recovery commands are much easier to reason about once you know which ref is current state and which ref is a saved previous state.

What HEAD Means

Most of the time, HEAD points symbolically to the current branch, and the branch points to the current commit.

You can inspect it with:

git rev-parse HEAD
git symbolic-ref HEAD

If you are on main, the .git/HEAD file usually contains:

ref: refs/heads/main

That means HEAD is not usually a raw commit hash. It is a symbolic ref to the branch you currently have checked out.

When you commit on that branch, the branch ref moves forward, and therefore HEAD moves with it.

Detached HEAD

If you checkout a commit directly instead of a branch, HEAD becomes detached:

git checkout 1a2b3c4d
git status

Now HEAD points directly to a commit. That is not an error. It just means you are no longer on a branch tip. You can inspect files, test history, and even commit, but those commits are not attached to a branch unless you create one.

Detached HEAD is common during:

• debugging old revisions
• 'git bisect'
• release investigation

The warning exists because people often forget to save new commits they make in that state.

What ORIG_HEAD Means

ORIG_HEAD is a recovery ref. Git updates it before certain history-moving commands, especially ones that may need a quick rollback.

Typical commands that write it include:

• 'git merge'
• 'git pull'
• 'git rebase'
• 'git reset'

You can inspect it with:

git rev-parse ORIG_HEAD
git show --stat ORIG_HEAD

If you just performed a bad merge or reset, ORIG_HEAD often points to where you were immediately before that operation started.

A Useful Recovery Pattern

Suppose you run:

git reset --hard HEAD~1

and then realize you removed the wrong commit. Git often saved the pre-reset position in ORIG_HEAD, so you can restore it:

git reset --hard ORIG_HEAD

The same idea often works after a merge:

git merge feature-branch
git reset --hard ORIG_HEAD

This is why ORIG_HEAD is worth knowing. It acts like a recent checkpoint for risky commands.

HEAD Versus ORIG_HEAD

The operational distinction is simple:

• 'HEAD is where you are now'
• 'ORIG_HEAD is where Git remembered you were before a significant move'

HEAD changes all the time as you checkout, commit, and reset. ORIG_HEAD changes only for certain commands, and later operations can overwrite it. That is why ORIG_HEAD is useful but temporary.

When reflog Is Better

If ORIG_HEAD no longer points to the place you need, use the reflog:

git reflog

The reflog records many past positions of HEAD and branch refs. ORIG_HEAD is one recovery hook; reflog is the fuller movement history.

A practical rule is:

• use HEAD to refer to the current commit
• use ORIG_HEAD for quick recovery after a recent major operation
• use reflog when the recovery target is older or ORIG_HEAD has already changed

Common Pitfalls

• Assuming ORIG_HEAD is updated for every Git command.
• Treating detached HEAD as a broken repository state when it is often completely intentional.
• Expecting ORIG_HEAD to be permanent even though later commands can overwrite it.
• Forgetting that git reflog is usually the better recovery tool for anything beyond the most recent major move.

Summary

• 'HEAD represents your current position in Git history.'
• Detached HEAD means HEAD points directly to a commit instead of to a branch.
• 'ORIG_HEAD is a saved previous position Git often records before risky history changes.'
• It can help undo a recent merge, pull, rebase, or reset.
• For broader recovery, use git reflog instead of relying only on ORIG_HEAD.