Viewing a Deleted File in Git
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
A file deleted from the working tree is not gone from Git history. As long as the file existed in some commit that Git can still reach, you can inspect its old contents, find the commit where it was removed, and even restore it if needed. The main task is to ask Git for the file as it existed in an earlier revision rather than looking for it in the current checkout.
Find the Deletion in History First
A good first step is to locate the commits that affected the file.
If you specifically care about deletions, use:
This tells you where the file was removed and gives you the commit history you need to inspect the last existing version.
View the File from an Earlier Commit
Once you know a commit where the file still existed, use git show to print its contents without restoring it into the working tree.
Or with an explicit commit hash:
This is often the fastest way to “view a deleted file” because it does not modify your working directory at all.
Find the Last Existing Revision Automatically
If you do not want to guess which commit still contained the file, use git log with --follow when the file may also have been renamed historically.
Then inspect the most recent commit before deletion and show the file from there.
This is especially helpful when the deletion happened long after a rename, because plain path-based history can otherwise be misleading.
Restore the File If Viewing Is Not Enough
If you decide you want the file back in your working tree, restore it from an earlier commit.
With modern Git:
With older syntax:
This puts the historical version back into your working directory so you can inspect or recommit it.
Show the Commit That Deleted It
Sometimes the important question is not the content of the deleted file but who removed it and why. In that case, inspect the deletion commit itself.
Then:
This reveals the surrounding diff and commit message, which often explains whether the deletion was intentional cleanup, refactoring, or an accidental removal.
If the File Was Deleted but Not Yet Committed
If the deletion exists only in your working tree and has not been committed, the solution is simpler. Git still knows the file from HEAD, so you can view or restore it directly.
To restore it:
To inspect what changed:
That is a different case from a historical deletion, so it helps to distinguish between “deleted in history” and “deleted locally right now.”
Reflog Helps Only in Some Cases
If commits themselves were lost through reset or rebase, git reflog can help you find prior commit references:
But for an ordinary deleted file that still exists in normal branch history, git log and git show are usually enough. Reflog is more relevant when the commit containing the file seems to have disappeared from the branch tip.
Common Pitfalls
The most common mistake is searching only the current working tree and forgetting that Git history stores prior file snapshots.
Another mistake is restoring the file immediately when all you needed was git show to inspect it. Viewing is often safer than changing the working tree first.
Developers also forget --follow when renamed files are involved, which can make history look shorter than it really is.
Summary
- A deleted file can usually be viewed from Git history as long as the relevant commit is still reachable.
- Use
git logto find the relevant commit andgit show commit:pathto inspect the old contents. - Use
git restore --sourceif you want to bring the file back into the working tree. - Distinguish between files deleted in committed history and files deleted only locally.
- When renames are involved,
git log --followoften gives a more complete history.

