What you can do with that reference varies by the command you select In layman terms it’s used to answer the question of: WHERE should I go? To which commit?

• HEAD means (the reference to the) current commit
• HEAD~1 means (the reference to) 1 commit before
• HEAD~ ALSO means (the reference to) 1 commit before
• HEAD~87 means (the reference to) 87 commits before
• HEAD~3..HEAD means from 3 commits to current commit (in total 3 commits)

---

Usage:

• git checkout HEAD~1 will actually GO/checkout to 1 commit/reference before
• git reset HEAD~3 will uncommit your last 3 commits — without removing the changes, ie you can see all the changes made in the last 3 commits together, remove anything you don’t like or add onto it and then commit them all again.
• git reset --hard HEAD~3 will uncommit your last commit and remove their changes. It will completely remove those changes.
• git diff HEAD~3 to look into the changes of the last 3 commits
• git diff someFile HEAD~3 to look into the last 3 changes of a specific file
• git revert --no-commit HEAD~3..HEAD. Reverts 3 commits, without automatically commiting i.e. you have to do git commit -m yourself.
• git rev-parse HEAD~2 outputs the SHA of two commit before.
• See all changes between a pull request and main. It’s a multi-step process.

git fetch origin/feature22
git checkout feature22
git merge-base feature22 main # will return the SHA of their 050dc022f3a65bdc78d97e2b1ac9b595a924c3f2
git reset 050dc022f3a65bdc78d97e2b1ac9b595a924c3f2

You could just do git reset main, but that only works if your colleague who created the pull request has the latest changes with main. If they’re working on a big feature (and haven’t merged with main for a couple days) and you just want to see what additions they have after their last pull from main, then you have to follow the steps above.

More Detail:

Make sure you see this answer for What is a detached HEAD. It has some good info on cat .git/HEAD

---

Out of scope, but super interesting: Other than HEAD, there are other kinds of heads. See git revisions: ORIG_HEAD

ORIG_HEAD is created by commands that move your HEAD in a drastic way, to record the position of the HEAD before their operation, so that you can easily change the tip of the branch back to the state before you ran them

To undo a git merge

git reset --hard ORIG_HEAD

ORIG_HEAD: is set only as part of something dangerous like a hard reset, where the old head would otherwise have no reference.

MERGE_HEAD I got this error message after I tried to merge again before concluding an existing merge

fatal: You have not concluded your merge (MERGE_HEAD exists). Please, commit your changes before you merge.

To fix this, I had to conclude my merge. Then do another merge. FETCH_HEAD

records the branch which you fetched from a remote repository with your last git fetch invocation

CHERRY_PICK_HEAD

records the commit which you are cherry-picking when you run git cherry-pick.

---

More official explanation

Highly recommend to see this page from the docs. Git as a system manages and manipulates three trees in its normal operation. (By “tree” here, we really mean “collection of files”, not specifically the data structure.) The role of HEAD is:

HEAD is the pointer to the current branch reference, which is in turn a pointer to the last commit made on that branch. That means HEAD will be the parent of the next commit that is created. It’s generally simplest to think of HEAD as the snapshot of your last commit on that branch.

tldr HEAD is always moving you in between commits, it doesn’t help you move between staging steps or sandbox.