How to Fix Git "fatal: bad object" Error During git pull From Remote Repository

Running git pull fails with a "bad object" error naming a specific commit hash, meaning Git's local object database has a reference to something it can't actually find or read correctly. This points at some form of local repository corruption — a missing, truncated, or damaged object file within .git — rather than anything wrong with the remote repository itself.

The Problem

A routine pull fails with a specific, cryptic error naming an object hash:

$ git pull origin main
error: bad object a1b2c3d4e5f6789012345678901234567890abcd
fatal: Failed to traverse parents of commit 'a1b2c3d4e5f6789012345678901234567890abcd'

Running basic integrity checks on your local repository often surfaces the same corruption from a different angle:

$ git fsck
error: a1b2c3d4e5f6789012345678901234567890abcd: object corrupt or missing
missing blob a1b2c3d4e5f6789012345678901234567890abcd

Why It Happens

Every commit, tree, and file in Git is stored as an object identified by its content hash, and Git's history is essentially a graph of these objects referencing each other. "Bad object" means Git tried to look up an object by its hash and either found nothing at that location or found data that doesn't match what the hash promises — the local object database has become internally inconsistent. Common causes:

• Disk corruption or a failing drive physically damaging the .git/objects directory's contents.
• An interrupted Git operation — a process killed mid-write, a system crash, or a forced shutdown during a clone, fetch, or garbage collection that left object files incomplete or in an inconsistent intermediate state.
• A disk-full condition during a Git operation, causing an object to be only partially written before running out of space.
• Manual tampering with .git internals — someone (possibly a previous version of yourself) manually deleted or modified files inside .git/objects without going through Git's own commands.
• A syncing tool (like a cloud drive client) actively syncing the .git folder and interfering with files mid-write, which is a surprisingly common source of this exact corruption when a repository lives inside a Dropbox or Google Drive-synced folder.

The Fix

First, run a full integrity check to understand the actual scope of the corruption — a single missing object versus widespread damage require different levels of response:

git fsck --full

If it's isolated to one or a few objects that also exist on the remote (which is usually the case, since the corruption is almost always local rather than server-side), the most reliable fix is simply re-fetching from the remote, which will re-download the objects fresh:

git fetch origin
git reset --hard origin/main

This discards any local uncommitted changes and any local commits not yet pushed — before running it, back up anything valuable by copying the working directory elsewhere, since a hard reset can't be undone if you didn't preserve unpushed work first.

If specific objects are corrupted but you have another local clone or a colleague's clone of the same repository, you can copy the missing objects directly from that good copy into your damaged repository's object store:

# From a known-good clone
cp /path/to/good-clone/.git/objects/a1/b2c3d4e5f6789012345678901234567890abcd \
   /path/to/broken-repo/.git/objects/a1/

Verify the specific object is now readable after copying it in:

git cat-file -p a1b2c3d4e5f6789012345678901234567890abcd

For more widespread corruption, or if you're not confident isolating exactly what's damaged, the simplest and most reliable fix is often just re-cloning the repository fresh entirely, rather than trying to surgically repair a corrupted local object database:

cd ..
mv yourrepo yourrepo-broken  # keep it around briefly in case you need to recover anything
git clone https://github.com/youruser/yourrepo.git
cd yourrepo

Manually reapply any local, unpushed work from the broken copy into the freshly cloned one before discarding the broken directory entirely.

Still Not Working?

If corruption keeps recurring even after a fresh clone, investigate the underlying cause rather than just repeatedly re-cloning as a workaround — check whether the repository lives inside a folder actively synced by a cloud storage client (Dropbox, Google Drive, OneDrive), since these tools syncing files mid-write while Git is also actively writing to the same files is a well-known source of repeated, recurring Git corruption:

pwd
# Check if this path is inside a cloud-sync-monitored folder

If it is, move the repository outside of any cloud-sync folder entirely — Git repositories should be versioned through Git itself (pushing to a remote), not through a general-purpose file-syncing tool running in parallel, since the two systems' independent write patterns to the same files are fundamentally incompatible and will keep causing this same class of corruption indefinitely.