Recovering lost files in Git after hard resets

🔧 How I Recovered a Lost File After git reset --hard in Git

Disclaimer: You are not guaranteed that you can recover the lost file from your Git repo's dangling blogs, much of this information is kept only for a few weeks. Therefore, you should run recovery of a lost file in Git repo as soon as possible or within a few weeks.

Have you ever added a file in Git, only to lose it after running git reset --hard? I did — and I managed to recover it using a lesser-known Git command: git fsck.

Here’s how it happened and how I got my file back.

💥 The Mistake

I created a file called fil2.txt, added it to Git with:

git add fil2.txt

But before committing it, I ran:

git reset --hard

This command wipes out all uncommitted changes, including files that were staged but not yet committed. My file was gone from the working directory and the staging area.

🕵️‍♂️ The Recovery Trick: git fsck

Thankfully, Git doesn’t immediately delete everything. It keeps unreferenced objects (like blobs) around for a while. You can find them using:

git fsck --lost-found

This listed several dangling blobs — unreferenced file contents:

dangling blob fb48af767fd2271a9978045a971c2eee199b03b7

🔍 Finding the Right Blob

To inspect the contents of a blob, I used:

git show fb48af767fd2271a9978045a971c2eee199b03b7

It printed:

dette er en fil som jeg fil recovere

That was my lost file!

💾 Restoring the File

To recover it, I simply redirected the blob’s contents back into a file:

git show fb48af767fd2271a9978045a971c2eee199b03b7 > fil2.txt

And just like that, fil2.txt was back in my working directory.

✅ Lesson Learned

• git reset --hard is powerful — and dangerous.
• If you lose a file, don’t panic. Try git fsck --lost-found.
• You might be able to recover your work — even if it was never committed.

Additional Tips - More detailed dangling objecst information

Git Alias: Dangling Object Summary

This Git alias defines a shell function that summarizes dangling objects in your repository, showing type, SHA, commit metadata, and blob previews.

[alias]
    dangling-summary = "!sh -c '\
        summarize_dangling() { \
            git fsck --full | grep dangling | while read -r _ type sha; do \
                echo -e \"\\033[1;33mType:\\033[0m $type\"; \
                echo -e \"\\033[1;33mSHA:\\033[0m $sha\"; \
                case $type in \
                    commit) \
                        author=$(git show -s --format=%an $sha); \
                        date=$(git show -s --format=%ci $sha); \
                        msg=$(git show -s --format=%s $sha); \
                        echo -e \"\\033[1;33mAuthor:\\033[0m $author\"; \
                        echo -e \"\\033[1;33mDate:\\033[0m $date\"; \
                        echo -e \"\\033[0;32mMessage:\\033[0m $msg\" ;; \
                    blob) \
                        preview=$(git cat-file -p $sha | head -n 3 | cut -c1-80); \
                        echo -e \"\\033[0;32mPreview:\\033[0m\\n$preview\" ;; \
                esac; \
                echo -e \"-----------------------------\"; \
            done; \
        }; \
        summarize_dangling'"

Screenshot showing the detailed dangling objects summary :

💡 Tips for Using This Alias

• Run git dangling-summary inside any Git repository to inspect unreachable objects.
• Useful for recovering lost commits or inspecting orphaned blobs.
• Blob previews are limited to 3 lines, each up to 80 characters wide for readability.
• Commit metadata includes author and timestamp for better context.
• If you did not commit the file, just added it to your Git repo and then for example did a hard reset or in some other way lost the file(s), there will not be shown any date and author here. The example screenshot above shows an example of this. If you DID commit, author and date will show up.

Share this article on LinkedIn.