Recovering deleted GitHub files: what actually works (and what doesn't)

Deleting the wrong file in a GitHub repo happens to everyone eventually. A merge gone sideways, a rogue git push --force, a "cleanup" PR that removed too much, or an AI agent that decided a whole folder was unused. The good news: if the file ever lived in Git, it is almost always recoverable. The bad news: Git only helps for files it actually tracked, and only inside your local reflog window.

This is the exact order we walk Backup247 users through when they open a ticket about lost GitHub files.

1. Was the file ever committed?

Start here. If the file was staged and committed at least once, you're in a strong position — Git keeps every object it has ever seen until garbage collection runs. If the file was only in your working directory (never git added) and you deleted it locally, Git cannot help you. Check your editor's local history, your OS trash, or a file-system snapshot (Time Machine, OneDrive version history, Dropbox rewind).

2. Recover a file deleted in a specific commit

If you know the commit that removed it, this is a one-liner:

git log --diff-filter=D --summary -- path/to/file
git checkout <commit-before-deletion>^ -- path/to/file

The first command finds the commit that deleted the file. The second restores the file from the commit just before it, into your working tree. Commit it and push — done.

3. Recover after a force-push wiped your branch

A git push --force or --force-with-lease doesn't actually delete commits on GitHub immediately. They live in the reflog on any machine that had the branch checked out, and in GitHub's internal reflog for roughly 90 days.

Locally:

git reflog show <branch>
git checkout -b recovery <sha-from-reflog>

On GitHub, if no one has a local copy, contact GitHub Support with the repo URL and the approximate time of the force-push. They can restore from their internal reflog while the objects are still reachable.

4. Restore from a Pull Request that was closed or deleted

GitHub keeps the commit refs of every PR under refs/pull/<n>/head even after the PR is closed and the branch deleted. You can fetch them directly:

git fetch origin pull/1234/head:pr-1234
git checkout pr-1234

This works for merged, closed, and even deleted-branch PRs, as long as the repo itself still exists.

5. The whole repository was deleted

If someone (or an automation) deleted the repo itself, GitHub retains it for 90 days. The repo owner or an org admin can restore it from Settings → Repositories → Deleted repositories within that window. After 90 days, GitHub cannot help. This is the scenario where a real, external backup matters most.

6. What Git and GitHub genuinely cannot recover

• Files that were never committed. Uncommitted working-directory changes are invisible to Git.
• LFS objects garbage-collected after a force-push. Git LFS runs its own pruning schedule; large binaries can vanish permanently.
• Repos deleted more than 90 days ago. GitHub's retention window is hard.
• Content in wikis, issues, discussions, releases, and Actions artifacts after a repo deletion. These are not part of Git objects and are lost with the repo.
• Secrets and environment variables. GitHub does not retain deleted secret values, by design.

How Backup247 fills those gaps

Backup247's GitHub connector treats a repository the way we treat an Airtable base: a live source of truth that needs an independent, off-platform copy. Every backup captures:

• The full commit graph of every branch (not just the default branch), including tags and refs
• All refs/pull/*/head references, so closed and deleted PRs stay recoverable
• Git LFS objects, resolved and stored alongside the commit snapshot
• Repository metadata: description, topics, default branch, protection rules
• Issues, PR discussions, releases, and wiki content, exported as structured JSON

Snapshots run hourly on Silver and Gold plans. A restore drops the repo (or any subset of files, or a single PR branch) into a new repository in your org, so your live repo is never overwritten. If a force-push wiped a branch three weeks ago, or an integration deleted a whole repo last month, restore is a few clicks — no ticket to GitHub Support, no reflog spelunking on a laptop no one has anymore.

A simple rule

If a file was committed to Git in the last week and pushed to GitHub, you can almost certainly get it back with the commands above. Anything older, anything force-pushed, anything lost with a deleted repo, and anything outside Git objects (issues, releases, LFS, wiki) needs an external backup. That is exactly the gap Backup247 was built to close.