Photo by Growtika on Unsplash

So I was doing a routine git pull on a Friday afternoon — of course it was Friday — and suddenly my terminal just barfs out this cryptic error that I'd never seen before. The repo wouldn't pull, wouldn't push, wouldn't even log cleanly. Corrupted git refs. Just sitting there, broken, while I'm staring at the clock thinking about my weekend plans evaporating. If you've ended up here, you're probably in the same boat, so let's just get into it.

What the Error Actually Looks Like

The symptoms can vary a bit depending on how the corruption happened, but here are the most common error messages you'll see when dealing with corrupted git references:

error: bad ref for .git/refs/heads/main
fatal: loose object [hash] (stored in .git/objects/...) is corrupt
error: Could not read [hash]
warning: reflog of 'refs/heads/main' references pruned commits
fatal: packed-refs file cannot be parsed

Sometimes you'll also see Git complain during a git status or even a simple git log — which is honestly the most alarming version because those are supposed to be read-only, harmless commands. When those break, people panic. Understandably.

Why Does This Even Happen?

Git refs are basically just tiny text files inside .git/refs/ that point to commit hashes. That's it. But they can get corrupted in a surprisingly large number of ways. The most common culprits I've seen over the years:

Power loss or force-quit during a write operation. Git is writing to a ref file, your laptop dies, the file ends up half-written or empty. This is probably the #1 cause. If you're on a dev machine and you're hard-shutting things down while Git operations are running, expect this eventually.

Filesystem issues. Bad sectors, NFS mounts with flaky connections, synced folders (looking at you, Dropbox-synced repos — please just don't), or container volumes that got interrupted mid-write. I've seen Dropbox absolutely mangle a .git directory when two machines were trying to sync simultaneously. Never again.

Disk space exhaustion. Git starts writing, runs out of space, leaves a corrupted or empty file behind. Check your disk space if you're not sure what caused this — df -h real quick before you do anything else.

Concurrent Git processes fighting each other. CI systems that run multiple Git operations in parallel on the same working directory can sometimes cause this. It's rare, but I've seen it in messy pipeline configurations.

Fix #1 — Run the Built-In Git Repair Tools First

Before you do anything drastic, let Git try to fix itself. The git fsck command is your first stop — it checks the integrity of your object database and reports what's broken.

git fsck --full

This will output a list of dangling commits, missing blobs, and corrupted objects. Read through it carefully. Now here's where it gets a little more useful — you can also run:

git gc --prune=now

This forces garbage collection and prunes loose objects. Sometimes git gc alone will clean up corrupted loose objects and get you back on track. It's not guaranteed, but it's zero-risk and worth trying before anything else.

Fix #2 — Manually Repair or Delete the Corrupted Ref

If git fsck pointed you to a specific ref that's bad, you can often fix it manually. First, look at the corrupted ref file:

cat .git/refs/heads/your-branch-name

If the output is empty or gibberish, that's your problem right there. You can repair it by pointing it back to a valid commit hash. If you know the last good commit (check git reflog if it's still working), just write the hash directly:

echo "your-valid-commit-hash" > .git/refs/heads/your-branch-name

Alternatively, if the bad ref is for a branch you can just rebuild from remote, sometimes the cleanest move is to just delete the corrupted local ref entirely and re-fetch:

git update-ref -d refs/heads/your-branch-name
git fetch origin your-branch-name
git checkout your-branch-name

Honestly, if the branch only exists locally and you can reconstruct it, this is the fastest path. Don't overthink it.

Fix #3 — Repair the packed-refs File

Sometimes the corruption lives inside .git/packed-refs rather than the individual ref files. This is a single file that Git uses to store a bunch of refs efficiently. Open it up and look for anything obviously wrong — empty lines in weird places, truncated hashes, lines that don't follow the [hash] refs/heads/branchname format.

cat .git/packed-refs

If you spot a malformed entry, you can edit the file directly (back it up first — cp .git/packed-refs .git/packed-refs.bak) and remove the bad line. Then run:

git pack-refs --all

This rewrites the packed-refs file cleanly from current state. After this, do another git fsck to make sure you're clean.

Fallback: Clone From Remote and Transplant Your Work

Alright, if none of the above is working and your repo is just totally hosed, don't despair. This is the nuclear option but it works. If your remote (GitHub, GitLab, Bitbucket, whatever) is intact, do a fresh clone somewhere else:

git clone https://your-remote-url.git repo-clean

Then copy over any uncommitted working changes from your broken repo manually, or if you have commits that didn't get pushed, use git format-patch to extract them from the broken repo first:

cd broken-repo
git format-patch origin/main --stdout > my-unpushed-work.patch
cd ../repo-clean
git am < ../broken-repo/my-unpushed-work.patch

This is honestly the most reliable recovery path when the object database itself is corrupted beyond what fsck and gc can repair. Don't be too proud to just re-clone — I've wasted hours trying to surgically fix a repo that I should've just cloned fresh in ten minutes.

One last thing — after you're recovered, take a look at what caused it. If it was a synced folder, move your repos out of it. If it was a CI pipeline, add locking. Corrupted git refs repair is usually a one-time fire drill, but only if you fix the root cause too. Hope this saves you a Friday afternoon.

Related: How to Fix Git Error: Cannot Lock Ref (And Why It Keeps Happening)