Debug Git Problems: Corrupted Repos, Missing Commits, and More (2026)

A Git repository is fundamentally a directed acyclic graph (DAG) of commit objects, where each commit points to its parent(s). When this structure becomes corrupted, Git can no longer traverse it, leading to various errors.

Corrupted Repositories

The Problem: Git is complaining it can’t find a specific object or a reference is broken. This often manifests as fatal: bad object <hash> or error: inflate: data stream error (incorrect data checksum).

Common Causes & Fixes:

Disk I/O Errors or Interrupted Operations: A git gc, git push, or git pull was interrupted while writing objects to disk. This is the most common culprit for outright corruption.
- Diagnosis: Run git fsck --full. Look for output like dangling blob, dangling commit, or missing <type> <hash> and error: inflate: data stream error.
- Fix: Often, simply re-running the operation that failed can fix it. If git fsck reports missing objects, and you know they should be there (e.g., from a recent push), try fetching from a known good remote:
```
git fetch origin
```
  If the corruption is severe and git fsck shows broken links, you might need to replace the corrupted object. This is risky. If it’s a local branch that’s broken, you might have to reset it:
```
# Find the hash of the last known good commit on that branch
git reflog show <branch-name>
# Reset the branch to that good commit
git branch -f <branch-name> <good-commit-hash>
# Then, try to re-apply any commits that were lost
git cherry-pick <commit-hash-1> <commit-hash-2> ...
```
  This works because Git objects are immutable. If an object is corrupted, it’s usually a sign of a read/write error on disk or a partial write. Fetching from a remote re-downloads the object, replacing the bad copy. Resetting a branch bypasses the broken commit chain and recreates the branch pointer.
Filesystem Corruption (Beyond Git): The underlying filesystem has errors, which Git, like any application, will encounter.
- Diagnosis: Run your operating system’s filesystem check tool (e.g., fsck on Linux/macOS, chkdsk on Windows). Also, git fsck --full.
- Fix: Repair the filesystem using the OS tools. After the filesystem is healthy, Git operations should resume. If Git still reports issues, try git fsck --full again. If it shows dangling objects, you can prune them:
```
git prune
git gc
```
  Filesystem repair ensures the storage medium is reliable. git prune removes unreachable objects that fsck might have flagged as "dangling" but are no longer needed. git gc then cleans up the repository.
Antivirus/Backup Software Interference: Real-time scanners or backup processes locking or modifying Git’s internal files (.git/objects/, .git/refs/) during Git operations.
- Diagnosis: This is hard to diagnose directly from Git errors. Look for intermittent issues, especially after a file is added or modified. Check your antivirus logs or backup schedules.
- Fix: Configure your antivirus and backup software to exclude your Git repository directories (especially the .git folder) from real-time scanning and backups.
```
# Add .git directory to exclusion list in your AV software
# Configure backup software to skip .git directories
```
  This prevents external processes from interfering with Git’s internal file operations, ensuring data integrity.
Incorrect Manual File Manipulation: Someone (or a script) directly edited, moved, or deleted files within the .git directory.
- Diagnosis: git fsck --full will likely report missing objects or broken symbolic links within .git/objects/.
- Fix: The safest approach is to re-clone the repository. If that’s not feasible, try fetching from a remote:
```
git fetch --all
git remote prune origin # if origin is the only remote
git gc
```
  If the corruption is limited to a specific local branch, resetting that branch as described in cause #1 can help. Re-cloning is the most robust fix because it rebuilds the .git directory from scratch using a known good copy from the remote.
Hardware Issues (RAM/SSD/HDD): Faulty RAM or storage devices can corrupt data as it’s written or read.
- Diagnosis: Persistent, widespread corruption across multiple operations and repositories. git fsck --full might show varying errors on repeated runs. OS-level disk checks (fsck, chkdsk) might also report errors.
- Fix: Run hardware diagnostics (e.g., memtest86+ for RAM, manufacturer tools for SSD/HDD). Replace faulty hardware. After hardware is fixed, you’ll likely need to re-clone repositories or fetch from remotes to ensure data integrity.
Git Bug (Rare): While uncommon, bugs in Git itself can lead to corruption, especially in edge cases or with specific configurations.
- Diagnosis: If you’ve exhausted all other possibilities, and the corruption is reproducible, check Git’s issue tracker or mailing lists for similar reports.
- Fix: Update Git to the latest stable version.
```
# Example for Ubuntu
sudo apt update && sudo apt upgrade git
# Example for macOS with Homebrew
brew upgrade git
```
  Newer versions often contain bug fixes that address such issues.

The Next Error You’ll Hit: If you fix all corruption and git fsck passes cleanly, the next error you’ll likely encounter is a normal "nothing to commit, working tree clean" or a successful git status output.

Missing Commits

The Problem: You’ve lost a commit, or a branch seems to have diverged unexpectedly, showing fewer commits than you expect. This isn’t usually corruption but rather a misunderstanding or accidental re-pointing of references.

Common Causes & Fixes:

Accidental git reset --hard or git checkout <commit-hash>: You were on a branch, performed a git reset --hard to an older commit, or checked out a detached HEAD state and then made new commits. The original commits are still in the repository but are no longer reachable from any branch.
- Diagnosis: Use git reflog. This command shows a history of where HEAD and branch tips have pointed.
```
git reflog
```
  Look for the SHA-1 hash of the commit you believe is missing.
- Fix: If you find the missing commit’s hash in the reflog, you can restore it:
```
# Assuming the missing commit is 'abcdef1'
git checkout -b recovered-branch abcdef1
# Or if you want to put it back on the current branch
git reset --hard abcdef1
```
  The reflog is a local history of changes to your HEAD and branch pointers. Restoring a commit involves simply re-attaching a branch pointer to that commit’s SHA-1 hash.
Incorrect git rebase or git merge: A rebase or merge operation might have been aborted, or it might have resulted in a state where expected commits were unintentionally dropped or not integrated.
- Diagnosis: Check git log before and after the operation. If you suspect a specific rebase, check git reflog for entries related to rebase.
- Fix: If a rebase was aborted, Git usually leaves you in a state where you can resume or abort it. If commits were lost during a successful rebase or merge, you might need to use the reflog to find the SHA-1 of the state before the operation and reset to it, then re-attempt the operation carefully.
```
# Find the SHA-1 hash of the branch tip BEFORE the rebase/merge from reflog
git reset --hard <sha1-before-operation>
# Then try the rebase/merge again, paying close attention to the output
```
  This works by reverting the branch to its previous known good state and then attempting the operation again, allowing you to observe and correct any missteps.
Working on the Wrong Branch: You made commits, but you were on a different branch than you intended, or you switched branches before committing.
- Diagnosis: Use git log to see the commit history. Check the branch name at the top of the log.
- Fix: If the commits are on the wrong branch but are still reachable (i.e., you haven’t reset the correct branch), you can simply cherry-pick them to the correct branch or merge the incorrect branch into the correct one. If you accidentally switched branches before committing, the commits might be in your reflog.
```
# If commits are on 'feature-a' but should be on 'main'
git checkout main
git merge feature-a
# Or if they are recent and on 'main' but you wanted 'feature-b'
git checkout feature-b
git cherry-pick <commit-hash-1> <commit-hash-2>
```
  This is about redirecting Git’s pointers. Cherry-picking copies specific commits, while merging integrates branches.
Force Pushing Overwriting History: A force push (git push -f or git push --force-with-lease) from another contributor (or yourself) overwrote a branch with a shorter history.
- Diagnosis: Check the remote history using git log origin/<branch-name>. Compare it with your local git log <branch-name>.
- Fix: If you or a colleague force-pushed, your local history might be outdated. Use git fetch to get the latest remote state. If the desired commits are no longer on the remote branch, and they were local to your machine, they might still be in your git reflog.
```
git fetch origin
# If the remote branch is now shorter, and you know the SHA-1 of the missing commit locally:
git reflog
# Find the SHA-1 of the lost commit
git checkout -b recovered-branch <lost-commit-sha1>
# Then you might need to rebase or merge this back into the remote branch after discussion
```
  This scenario requires communication. If a force push lost data, the lost commits are only recoverable if they exist in someone’s local reflog. The git fetch updates your view of the remote.
Accidental Branch Deletion: A branch was deleted locally or remotely without proper archiving.
- Diagnosis: Check git branch -a to see local and remote-tracking branches. Check git reflog for commits that were previously pointed to by that branch.
- Fix: If the branch was deleted locally but the commits are still reachable from HEAD or reflog, you can recreate the branch:
```
# If the branch was deleted locally, and the commits are still on HEAD
git checkout -b <branch-name>
# If the branch was deleted and you need to find its last commit from reflog
git reflog
# Find the SHA-1 of the last commit on the deleted branch
git checkout -b <branch-name> <last-commit-sha1>
```
  If the branch was deleted remotely, you might need to recreate it locally and push it back up.

The Next Error You’ll Hit: Once you’ve recovered missing commits, the "next error" is usually reintegrating them correctly, which could lead to merge conflicts if other work has been done on the target branch.