Recovering Deleted Files From Your Git Working Tree — Smashing Magazine

The Lifecycle of a File in Git

Before a file ever reaches a remote repository, it exists in three distinct states in your local Git environment. Initially, files exist only in your working tree — they are untracked and Git has no record of them. Running git add <filename> (or git add -A) moves files into the staging area, or index. Under the hood, Git hashes each file's content and creates a blob object that is stored in the .git/objects directory.

Once files are staged, they can be included in commits. When you commit, Git creates a tree object containing the SHA-1 hash of the repository state, the parent commit's hash, author and committer information, and the commit message. Only after a git push do those objects reach your remote host — GitHub, Bitbucket, or otherwise.

Where Files Get Lost

Files can disappear from your project at any point, but deletions from the working tree are the hardest to reverse. Several Git commands are common culprits, and knowing which scenario applies to you matters for choosing the right recovery approach.

git rm

This command removes files from the working tree explicitly and is the most direct way to delete a file.

git reset

Two variants of git reset can cost you files:

1. git reset --hard
   This is a destructive reset of both the working tree and staging area. Any uncommitted changes are lost, and files not present in the HEAD commit are removed entirely.
2. git reset <filename>
   Less damaging, but it does remove the named file from the working tree. The file remains in the staging area, which gives you a path back.

git clean

Untracked files — temporary files or anything not yet added to the repository — are removed by git clean. It respects .gitignore by default and never touches staged or committed files. Variations include:

• git clean <filename> — removes a specific file.
• git clean -d — removes untracked files from a directory.
• git clean -i — interactive confirmation before removal.
• git clean -n — dry run; previews what would be removed.
• git clean -f — forces removal of all untracked files, including ignored ones.
• git clean -f -d — forces removal of directories as well.
• git clean -x — removes all untracked files including build products.
• git clean -X — removes only files ignored by Git.

Files can also be deleted manually through your file manager. In that case, the staging area is untouched, and CMD + Z/CTRL + Z might undo the action if nothing else has happened since. Manual deletions of uncommitted files are otherwise effectively impossible to reverse from Git's perspective.

Recovery Strategies by Scenario

Four Git commands — git checkout, git reset, git restore, and git reflog — cover most recovery paths, each suited to a particular situation depending on whether the deletion was committed and whether you want to preserve other working tree changes.

git checkout

If the deletion was not committed, git checkout restores files by resetting the working tree to the contents of a previous commit, branch, or tag.

When you only want to fall back to the most recent commit:

git checkout HEAD~ <filename>

If the file was deleted several commits back, specify a commit hash:

git checkout <commit-hash> <filename>

To restore the entire working tree without knowing which files were lost, you can use a similar checkout against the whole tree:

git checkout <commit-hash>

git reset

When the deletion has been committed, git reset moves the HEAD pointer to an earlier commit, restoring deleted files in the working tree as a side effect:

git reset <commit-hash>

git restore

If you need to bring back deleted files without touching other working tree changes, git restore is the tool. Note that it works only on tracked files — anything never added via git add is out of reach.

git restore --staged <filename>

You can restore from the working tree rather than the staging area by specifying the --worktree target:

git restore --worktree <filename>

Omit the filename to restore all files from the previous commit:

git restore --worktree

Alternatively, restore every file in the current directory:

git restore .

git reflog

The git reflog command logs recent HEAD movements, making it useful for identifying the exact commit to checkout or reset toward when you are not sure where things stood:

git reflog

When the Working Tree Is All You Had

Files deleted from the working tree that were never staged or committed are normally considered unrecoverable. In practice, though, that is rarely the final word. Two approaches can often bring most or all of such files back.

Using File Recovery Applications

Data recovery tools scan storage devices at a low level to locate files that have been deleted or lost. They attempt to reconstruct every file and folder that has existed on the device, after which you can restore the ones you need to a new location. Some recovered files may be corrupted or damaged, but in most cases the majority come back intact.

Which tool is “best” is subjective, but a few well-known options are worth considering:

• Wondershare Recoverit supports more than 1,000 file formats. The free tier can scan and find files, but recovery requires a paid plan starting at $69.99 per year or a one-time $119.99 license. More expensive premium tiers add advanced recovery for video and corrupted-file repair.
• EaseUS Data Recovery Wizard is widely used. Its free tier performs deep scans and recovers up to 2GB of data. Paid subscriptions start at $119.95 per year, or $169.95 for a lifetime license, and remove the data limit. The Windows and macOS versions differ substantially, with the macOS offering costing more.
• DM Disk Editor (DMDE) uses a special algorithm to reconstruct directory structures, and can fall back on file-signature-based recovery when file-system recovery is impossible. The free tier allows recovery from a selected directory, up to 4,000 files at a time. Paid versions remove that restriction, starting at $20 per year and scaling to $133 per year for advanced features. The interface is less intuitive than its competitors.

These are only a few of the many available tools, and different situations may call for different ones.

The git fsck Fallback

git fsck can be dangerous if used incorrectly. Before attempting it, make sure you understand the command and its implications. If anything here is unclear, consult the Git documentation first.

When used properly, git fsck can recover files lost from the working tree — possibly as a true last resort. It scans the repository for “dangling” objects, which are objects not referenced by any commit. The Git docs define a dangling object as:

“An unreachable object that is not reachable even from other unreachable objects; a dangling object has no references to it from any reference or object in the repository.”

This can happen when files are deleted from the working tree but not committed, or when a branch is deleted while its files remain unreferenced.

To recover files this way, follow these steps:

1. Run git fsck --lost-found. This special mode creates a .git/lost-found directory and moves all lost objects there, organized into commits and objects subdirectories. Lost commits go in the former; blobs, trees, and tags go in the latter. The command also prints the dangling objects it finds.

2. Run git show <dangling_object_hash> for each printed object. This shows the object’s content, letting you identify which dangling blobs correspond to files you want back.
3. Recover the desired object. You can copy the content from the console output, run git show <dangling_object_hash> > <filename> to save it directly to a file, or use git checkout <dangling_object_hash> to restore it to the working tree.

After recovery, commit the restored files as usual. This method is only recommended after other options have been exhausted.

Avoiding the Problem Altogether

Knowing how to recover lost files eases the worry, but prevention is always better. Two habits will keep you out of this situation:

• Commit early and often. Push to remote servers as soon as files are created or changed. No commit is too small.
• Back up project files routinely. Regular backups protect against accidental deletion and hardware failure alike.