Recover lost workUsually recoverable

Repair a corrupted Git repository

Git says 'object file is empty' or 'loose object is corrupt' — can I repair it?

Short answer

Corruption is almost always a few damaged object files after a crash, disk problem or a killed process. Run git fsck to identify them, delete the empty or unreadable ones, and re-fetch the good copies from your remote. If you have a remote, a fresh clone is often the fastest fix.

quick fix

git fsck --full

Identifies exactly which objects are damaged or missing

Does this match your situation?

'error: object file .git/objects/ab/cdef... is empty'.
'fatal: loose object ... is corrupt'.
'error: bad signature' or 'index file corrupt'.
It started after a crash, power loss, full disk, or a killed Git process.

Step-by-step fix

Back up the whole folder before touching anything
Repair involves deleting files. Take a copy first so a wrong move doesn't make a recoverable situation permanent.
step 1
```
cp -r my-repo my-repo-backup
```
Show the PowerShell (Windows) version
PowerShell (Windows)
```
Copy-Item my-repo my-repo-backup -Recurse
```
Diagnose the exact damage
fsck checks every object and names the broken ones. Note the paths and hashes it reports — those are what you'll repair.
step 2
```
git fsck --full

# 'index file corrupt' only? that one is trivially fixable:
rm -f .git/index
git reset
```

Remove empty and corrupt loose objects

Zero-length object files are the classic result of a crash mid-write. They can't be repaired, only deleted and re-fetched.

step 3

find .git/objects/ -type f -empty -delete

# then let fsck confirm what's still missing:
git fsck --full

Show the PowerShell (Windows) version

PowerShell (Windows)

Get-ChildItem .git\objects -Recurse -File |
  Where-Object { $_.Length -eq 0 } |
  Remove-Item -Force
git fsck --full

Re-download the missing objects from your remote
If the repo is pushed anywhere, the good copies of those objects exist there. Fetching restores them without losing your local branches.
step 4
```
git fetch --all
git fsck --full     # should be clean now
```
Clear a broken reflog or ref if fsck still complains
Damaged reflog entries and refs are safe to remove — they're bookkeeping, not history. You lose undo depth, not commits.
step 5
```
rm -rf .git/logs
git reflog expire --stale-fix --all
git gc --prune=now
```
Deleting .git/logs destroys your reflog. Only do this once you've recovered anything you needed from it.
When repair isn't worth it, re-clone
If the work is pushed, a fresh clone is faster and guaranteed clean. Copy across any uncommitted files from the backup afterwards.
step 6
```
cd ..
git clone git@github.com:USER/REPO.git repo-fresh
# copy uncommitted work from the backup by hand
```

Why this works

Git's object database is a set of immutable, content-addressed files, and every object's name is the hash of its contents. That makes corruption easy to detect — the file no longer hashes to its own name — but impossible to repair in place, since there's no redundancy in a single copy. Recovery works because Git is distributed: the identical object almost certainly exists in your remote or a colleague's clone, and because objects are content-addressed, any copy is byte-for-byte interchangeable.

If that didn’t work

A colleague's clone or your remote can supply any missing object - copy .git/objects entries directly if a fetch won't reach them.
git cat-file -t <hash> on each reported hash tells you whether the missing object is a blob, tree or commit, and therefore how much is affected.
If your disk caused this, run a filesystem check before trusting the repository again.

How to stop it happening again

Push often - a remote is a complete, verified backup of every object.
Keep repositories off network drives and cloud-sync folders.
Don't kill Git mid-operation, and keep enough free disk space for it to finish writes.

Commands used in this guide

git fsck

Scan the object database for orphaned commits and blobs the reflog no longer lists.

git gc

Compress the repository and delete unreachable objects.

git fetch

Download new commits from the remote without changing any of your files.

git clone

Copy a remote repository, its full history and its branches, onto your machine.

git reflog

The undo history for everything - the single most important recovery command.

Still stuck?

Search the full command reference and every other rescue guide — there are 56 of them, covering everything from detached HEAD to force-push disasters.

Browse all guides →

Frequently asked questions

What does 'object file is empty' mean?

A file in .git/objects has zero bytes, which happens when Git was interrupted mid-write by a crash, power loss or a full disk. The object can't be repaired, but it can be deleted and re-fetched from a remote that has an intact copy.

Can I fix a corrupt repository without losing my commits?

Usually yes. Delete the damaged objects and re-fetch from your remote — because objects are content-addressed, the copies there are identical. You only lose commits that existed solely on the corrupted machine and were never pushed.

Is it faster to just re-clone?

Often, yes. If everything important is pushed, cloning fresh takes minutes and is guaranteed clean. Repair is worth attempting when you have unpushed commits that exist nowhere else.

Related rescue guides

Always fixable

Git says another git process seems to be running — how do I fix index.lock?

Git locks the index while it works and removes the lock when it finishes. A crashed command, a killed process or an editor's background Git integration can leave the lock behind. Confirm nothing is actually running, then delete .git/index.lock.

Read the fix →Sometimes recoverable

I permanently deleted a file that was never committed — can I get it back?

It comes down to one question: was the file ever staged with git add? If it was, its contents are sitting in Git's object database as a dangling blob and git fsck will find it. If it was never staged and never committed, Git genuinely never saw the file and cannot help — but your editor's local history almost certainly can.

Read the fix →Always fixable

My .git folder is enormous — how do I find the biggest files in history?

git count-objects -vH tells you the total size; combining git rev-list --objects with git cat-file --batch-check lists the largest blobs by name. Deleting the files now won't shrink anything — they have to be purged from history.

Read the fix →Usually recoverable

I ran git reset --hard and lost my commits — how do I undo it?

Committed work is almost never really gone. git reflog lists every position HEAD has held, including the one just before your reset, so you can jump straight back to it with git reset --hard HEAD@{1}. Uncommitted changes that the reset wiped are a different story — those are only recoverable if they had been staged at some point.

Read the fix →

← All Git Rescue guides