Recover a file you deleted before committing it

Does this match your situation?

• You deleted a file (or your editor did) and it never made it into a commit.
• It's not in the Recycle Bin or Trash, or you emptied it.
• git status doesn't mention the file at all.
• git checkout and git restore both say the file doesn't exist.

Step-by-step fix

1. First, work out whether Git ever saw the file

   Git only stores content it has been given. A file becomes recoverable the instant you run git add on it — even if you never committed — because staging writes the contents into .git/objects permanently. If you edited the file and deleted it without ever staging it, Git has nothing to give back and you should jump straight to step 5.

   step 1Copy

   git log --all --full-history -- "**/YourFile.cs"
   

   💡If this prints commits, the file was committed at some point and you're in luck — see 'Find a deleted file in history' instead, it's a much easier fix.

2. Ask Git for every orphaned object it still holds

   git fsck walks the whole object database and reports objects that nothing points to any more. A 'dangling blob' is exactly what a staged-but-never-committed file becomes once the index moves on. With --lost-found, Git writes each one into .git/lost-found/other/ as a real file you can open.

   step 2Copy

   git fsck --lost-found
   

   ✅Recovered blobs get hash-named files in .git/lost-found/other/. Open them in your editor and look for your content.

3. Search the dangling blobs for a line you remember

   If fsck returns dozens of objects, don't open them one by one. Print the first few lines of each blob and look for a class name, function or comment you know was in the file. This turns a pile of hashes into an obvious match in a few seconds.

   step 3Copy

   # Bash / Git Bash / macOS / Linux
   for blob in $(git fsck --lost-found | awk '/dangling blob/ {print $3}'); do
     echo "=== $blob"
     git cat-file -p "$blob" | head -5
   done
   

   Show the PowerShell (Windows) version

   PowerShell (Windows)Copy

   git fsck --lost-found |
     Select-String 'dangling blob' |
     ForEach-Object { ($_ -split ' ')[2] } |
     ForEach-Object { "=== $_"; git cat-file -p $_ | Select-Object -First 5 }
   

4. Write the matching blob back to disk

   Once you've identified the right hash, git cat-file -p prints its full contents. Redirect that into a file and your work is back exactly as it was when you staged it. Save it under a new name first so you don't overwrite anything that currently exists.

   step 4Copy

   git cat-file -p a1b2c3d4 > recovered-PlayerController.cs
   

   ✅Recovering gives you the file as of the last time you staged it — anything you typed after that git add is not in Git.

5. If Git never had it, use your editor's local history

   This is the step most guides skip, and it rescues more files than Git does. Modern editors keep their own timeline of every save, completely independently of version control, and it survives deleting the file. Check it before you accept the loss.

   step 5Copy

   VS Code      → Command Palette → "Local History: Find Entry to Restore"
   JetBrains    → right-click the folder → Local History → Show History
   Unity        → Library/ is regenerated, but check Assets/ in your editor's history
   Windows      → right-click the folder → Properties → Previous Versions
   macOS        → Time Machine, if enabled
   

   ⚠️JetBrains IDEs and VS Code both keep local history for days regardless of Git. This is your best chance for a never-staged file.

Why this works

Git is content-addressable: the moment you run git add, the file's contents are hashed and written into .git/objects as a blob, and that blob is never modified again. Committing simply adds a tree and commit object pointing at it. So a staged-but-uncommitted file physically exists in your repository — it just has nothing referencing it, which is what 'dangling' means. Those objects survive until git gc prunes them, typically after two weeks, which is your recovery window. A file that was never staged has no blob, and no amount of Git commands can invent one.

If that didn’t work

• Run git fsck --unreachable --no-reflogs, which surfaces objects the plain scan may treat as still-referenced.
• Check whether the file lives in another clone of the repo, on a colleague's machine, or in a CI build artifact.
• Look in your build output folders — compiled or copied versions of the file may still exist there.
• If it was ever opened in a browser-based editor or shared over chat, the attachment may still be retrievable.

How to stop it happening again

• Commit early and often on a scratch branch — a commit takes a second and makes anything recoverable for 90 days.
• Run git stash -u instead of deleting work in progress; stashes are real commits and are themselves recoverable.
• Turn on your editor's local history and increase its retention.
• Never run git clean -fdx to 'tidy up' without running git clean -nd first to see the list.

Commands used in this guide

Frequently asked questions