Which problem is yours
"How to recover my source code" is typed by two different people. The first still has the code in some form: a git repository on disk, a deleted branch, an old checkout, a copy on a server that still exists. The second has lost the code entirely and only has the compiled program: the .exe or library that runs. The fixes for these two problems share nothing except the name, so the first step is to tell them apart.
- You have a git repository, a clone, or any checkout, even an old one. Your problem is git recovery. The git section below is your fix.
- You deleted the repository or a branch but made commits before. Your problem is git history recovery. The reflog section covers it.
- You never committed, never cloned, and have no checkout. Your problem is file recovery, and it may already be unrecoverable. The honest options are below.
- You have the compiled program but no source anywhere. Your problem is binary recovery. Git has nothing to do with it, and the binary recovery section is your path.
If the code is in git history somewhere
Git is designed so that deleting a branch or checking out a different commit does not immediately destroy the commits. Start with the safe reads. Do not run git reset --hard or git clean -fd while diagnosing: those are the two commands that actually destroy recoverable work.
- Uncommitted changes you threw away on one file. If the file was committed at least once, git checkout <commit> -- <file> (or git restore --source <commit> <file> on current git) brings the committed version back. It cannot bring back edits that were never committed.
- Work you stashed. git stash list shows saved work; git stash apply brings the most recent one back. Stashed work survives branch switches and most resets.
- A branch you deleted. git reflog shows every place HEAD has pointed, including the tip of the deleted branch, for about 90 days by default. Find the commit, then git checkout -b rescue <sha> to put it back on a branch.
- A reset you regret. The same reflog covers it. Find where HEAD was before the reset, copy that tip onto a rescue branch first, then move HEAD back if you want. Keep two copies until you are sure.
- A repository you deleted that was cloned or pushed anywhere. The other copy is the recovery. Fetch from the remote, check other machines, check CI artifacts and old archives. Hosts like GitHub and GitLab keep the repository history as long as the repository itself still exists there.
- Truly unreachable objects. git fsck --lost-found finds commits that no branch or reflog entry points to anymore. It is a last resort, not a first step, and it recovers commits, not branch names.
If none of these produce anything, the code was probably never in git in the first place. That is the file recovery case or the binary recovery case, not a git problem, and running more git commands will not change that.
If you only have the compiled program
When the source is gone and the compiled program is all that remains, git is the wrong tool. A compiled program is machine code, not source code with a toggle. Recovering source from it is a different job: decompiling the binary, reconstructing readable source, rebuilding it, and proving the rebuild behaves like the original by running both side by side across thousands of generated test cases. That proof step is what separates a real recovery from a guess, and our guide to what recovery returns explains exactly what comes back (the logic and behavior) and what is lost for good (programmer chosen names and comments, which were never stored in the binary).
The measured record for this service: 9 of 9 C and C++ test targets recovered to compilable source with zero divergence in final differential testing, including an 8,127-line recovery of bzip2 1.0.8. The intake rule is simple and safe: email first, do not attach the binary, and the $45 Recon Report gives an honest verdict on whether the specific program qualifies before any full recovery work begins. Our work covers only binaries the client owns or has the right to reverse engineer.
If nothing exists anywhere
If there is no repository, no checkout, no clone, no archive, and no compiled program, then the code exists nowhere and no recovery technique can recreate it. Two honest options remain. First, backups: cloud sync trash folders, external drives, Time Machine or shadow copies, and editor local history (VS Code and JetBrains editors both keep local file history independent of git) often hold what feels lost. Second, file recovery tools run on the original drive, immediately and from another boot disk: stop using the drive first, because every write risks overwriting the deleted data. If the data was overwritten, it is gone, and any service that says otherwise is selling hope.
This is also why the git case is worth its five minutes of checking: the reflog is the cheapest recovery on this page, and many "lost code" stories are really uncommitted changes sitting in a stash.
Which problem does Orphanware Recovery solve
The compiled program case. Orphanware Recovery is a one operator service run from Coeur d'Alene, Idaho. The operator directs the work and AI agents run the pipeline under his direction. Prices are fixed and published: the $45 Recon Report in about 3 days, Source Recovery at a fixed $120 in about 5 days, and Verified Recovery at a fixed $250 in about 7 days, including the full differential test report. It does not do git recovery (you can do that yourself with the section above), chip off extraction, part only recreation, controller firmware or ladder logic, enterprise mainframe COBOL, or anything the client does not own or have the right to reverse engineer.
How to start
Start with the $45 Recon Report. Email us first and include what the program is, what it does for your business, where it came from if you know (vendor, approximate year, language or platform), and what you need (maintenance, a fix, a migration, or documentation). Do not attach the binary to your first email. After an initial reply, we arrange a safe transfer. Every inquiry gets a reply within one business day, from the operator, not an autoresponder.