How to fix fatal: bad object HEAD in Git

First, check the extent of repository corruption:

# Check repository integrity
git fsck --full

# Check for unreachable objects that might help recovery
git fsck --unreachable --no-reflogs

This reports missing objects, dangling commits, and other integrity issues. Note the error messages — they guide your recovery approach. Also inspect what HEAD currently points to, since an empty or garbage value is a common cause:

cat .git/HEAD

A healthy HEAD looks like ref: refs/heads/main (or a 40-character SHA for a detached HEAD).

If you have a remote repository, fetching often resolves the issue by re-downloading missing objects:

# Fetch all branches from origin
git fetch origin

# Re-download objects even if Git thinks it already has them (Git 2.29+)
git fetch --refetch

# If the above fails, try fetching a specific branch
git fetch origin main

After fetching, try git status again. This is the safest fix and works in most cases where the corruption was caused by sync issues or interrupted operations, because it only adds objects without rewriting your local state.

Before changing anything, find the commit HEAD should point to. The reflog records recent HEAD positions:

# View recent HEAD positions (preferred — uses Git's own parser)
git reflog

# If git reflog itself fails, read the raw log
cat .git/logs/HEAD

Each line ends with a 40-character SHA. Identify the most recent commit you trust. Verify the object actually exists and is readable before relying on it:

git cat-file -t <commit-hash>   # should print: commit

If this prints commit, the object is intact and you can repair the ref in the next step.

If a branch ref is empty or points to a missing object, repair it using Git's plumbing command rather than editing files by hand. git update-ref validates the hash and writes the ref atomically:

# Check what the branch ref currently holds
git rev-parse --verify refs/heads/main

# Point the branch at a known-good commit (validated, atomic)
git update-ref refs/heads/main <commit-hash>

# If HEAD itself is the problem, re-point it at the branch symbolically
git symbolic-ref HEAD refs/heads/main

Prefer git update-ref over echo <hash> > .git/refs/heads/main: the raw redirect skips validation, can write a malformed ref (trailing newline, wrong length, packed-ref conflicts), and silently makes corruption worse. Use the remote to find the correct hash if you are unsure:

git ls-remote origin main

Once HEAD and the branch ref resolve correctly, your working tree may still be out of sync. To align it, prefer a non-destructive reset first:

# Move the branch pointer but KEEP your working changes
git reset --mixed <commit-hash>
git status   # review what changed

Only if you are certain you have no uncommitted work to keep should you use a hard reset, which permanently discards all uncommitted changes in tracked files:

# DESTRUCTIVE: discards uncommitted changes — back them up first
git stash push -u            # save anything uncommitted just in case
git reset --hard <commit-hash>

Always inspect git status and stash or commit important changes before running git reset --hard.

If the problem is with the remote tracking HEAD (common after a default-branch rename such as master to main):

# Auto-detect and set the remote HEAD
git remote set-head origin --auto

# Clean up stale remote-tracking references
git remote prune origin

This updates refs/remotes/origin/HEAD to match the remote's actual default branch.

If the .git directory is severely corrupted but you have a remote and want to preserve your working files:

# Back up the existing .git folder first — do not delete it
mv .git .git.backup

# Reinitialize and reconnect the remote
git init
git remote add origin <your-remote-url>

# Fetch all data and restore your branch
git fetch origin
git checkout main

This keeps your working-directory files intact while replacing corrupted Git metadata. Afterward, check .git.backup for any uncommitted work (for example with git fsck --lost-found run against it) before deleting the backup.

As an alternative last resort, clone fresh and copy your working files across:

# Clone the repository to a new location
git clone <your-remote-url> repo-fresh

# Copy your current working files, excluding the corrupted .git
rsync -av --exclude='.git' ./ ../repo-fresh/

cd ../repo-fresh
git status

Review git status in the fresh clone to see which files differ, then commit the changes you want to keep. Keep the original corrupted directory until you have confirmed nothing was lost.

The git-repair tool (part of the git-annex project) can automate fsck-driven recovery:

# Install (Debian/Ubuntu)
sudo apt install git-repair

# Install (macOS)
brew install git-repair

# Run automated repair
git-repair

git-repair runs fsck and attempts various automated fixes, fetching from remotes where possible. It has a --force mode that proceeds even when data may be lost — avoid it unless you have first backed up the .git folder and exhausted the safer steps above.