If you are an organization enthusiast like me, you will be quick to hit the delete button on old repositories you’re no longer using. For personal projects, this is an effective way to keep your GitHub account clean. In shared organization accounts, it’s a great way to reduce the mental complexity of your codebase.
However, experienced programmers know the danger of carelessly deleting repositories. When you move too fast, essential files can easily get deleted, so it’s a good idea to establish backups on anything you don’t want to lose. Backups are mandatory for any type of database, so why not follow the same practice for valuable code?
Why would you want to delete a repository?
I find myself hitting the delete button on repositories just to keep my workspace as clean as possible. I’ve also had projects that began separately and merged later. In that case, one of the repos becomes deprecated and can safely be deleted. Sometimes a company flat out cancels a feature or product line in which case the code may sit around for a while before eventually being deleted. Finally, when forming a new GitHub organization where code is moved from a personal account, old repositories may no longer be needed.
Why would you want to recover a repository?
The main reason for wanting an old repo is that “Oh crap” moment when you realize you need to access an important file that’s now gone. Maybe it’s an old environment variable, a handcrafted .gitignore file, or a complicated configuration file that would be useful to copy. You could be re-implementing a feature and can’t remember the workaround for a specific browser incompatibility. You might have forgotten the name of a library you used before. You might want to check the issues in an old repository. You could just want to revive an old project that you gave up on previously.
Regardless of your reason, recovering deleted GitHub repositories is a pretty common task for developers. Fortunately, most repositories are recoverable, so read on to learn how.
Repository Recovery Method 1: Using the GitHub User Interface
So you just realized that you need to bring back an old repo. You’re sweating bullets because you fear it’s lost forever.
Fortunately, you might be able to recover your repository directly from GitHub. If you deleted your repo in the last 90 days and it is not a part fork network, you can recover directly in the GitHub UI. A fork network consists of a parent repository, the repository’s forks, and forks of the repository’s forks. If your repository was part of a fork network, it cannot be restored unless every other repository in the network is deleted or has been detached from the network.
The process differs slightly depending on whether your code is in a personal or organization’s account.
Recovering a Personal GitHub Repository
If you are recovering a personal repository that is not part of an organization, start by opening “Settings” in the top right dropdown menu.
Click on the “Repositories” menu item.
From that screen, you should see a section for deleted repositories in the top bar, click on that.
You’ll see that I have a repository that’s available for recovery. Any repo that was deleted within the last 90 days and is not part of a fork network (as mentioned above) should show up in this list. Be aware, GitHub advises that some repos may take an hour to show up after deletion.
Click Restore and a caution message will appear. Confirm it to bring your repository back.
After a few seconds, the repository will show a “Done!” message next to it, and you can find it in your personal repositories list.
Recovering an Organization’s GitHub Repository
If the repository you need to restore is a part of an organization, start from the organization page.
This time, the option for “Deleted repositories” is available directly from the organization settings.
Follow the same restoration steps as outlined above for recovering a personal repository.
GitHub’s solution is usually the right choice for individuals and smaller organizations whose deleted repositories meet the criteria. It’s essential to keep in mind that there is a 90-day limit, after which GitHub may not be able to recover your code. When you need a longer-term backup or you’re facing certain compliance requirements, there is a better solution.
Repository Recovery Method 2: BackHub
For those that need a little more peace of mind than what GitHub offers, a cloud solution like BackHub (now part of Rewind) may be the best option. While it’s a paid service, it offers several important features on top of simple repository recovery:
- Nightly backups
- Sync to Amazon S3
- Audit log
- Backing up issues, milestones, pull requests, etc.
- Restore directly to GitHub
- No 90-day limit on backup retention
If peace of mind is worth it to your team, then sign up for a free trial to give BackHub by Rewind a try. Here’s the process for installing and recovering a GitHub repository using BackHub.
How many GitHub users are in your organization?
Install BackHub
After signing up for a free trial, you’ll be directed to an install screen that sets up permissions with your GitHub account.
Select “All repositories” to back up everything or use the dropdown to choose the relevant repositories.
From there, log in to GitHub and authorize BackHub as an app.
Wait for a second for things to get set up…
Once BackHub is configured, you’ll be taken to the BackHub dashboard. You will see a list of all the repositories you selected, including a timestamp of the last backup. BackHub will keep your backups up to date so you can recover them at any time.
Here’s a sampling of some of the information it displays on each repository:
Restore from BackHub
To complete the process, try restoring a repository from BackHub’s backups. Since I just created my account, I know that it’s up to date with my latest code changes.
Click the Restore button in the repo dropdown.
In the restore popup, you will be asked to authorize the BackHub app again. This installs a temporary app that you can remove after restoration is complete.
Once the app is authorized click the Restore button in the BackHub dashboard again. You’ll get a chance to name your repo. In this case, I’ll stick with the default <REPOSITORY_NAME>-restored format and leave it private.
Once you hit restore, BackHub will get to work in the background. There is a status message at the top of the dashboard telling you the current state.
That will quickly change to a success message.
Now when I go to my GitHub account, I see the restored repository:
If your code is stored in a GitHub organization account, BackHub requires a new plan for each organization. These can be set up from the dashboard as well.
Conclusion
In this post, you’ve seen two methods for recovering deleted GitHub repositories. While GitHub’s UI offers a free solution, the 90-day time limit and failure to support forked repositories may hamper its utility. BackHub (now part of Rewind) allows you to store your backups in your own S3 bucket where they’re unaffected by GitHub downtime, but you have to plan ahead because it’s not built into GitHub by default.
Just like database backups, code backups should be considered early in the software development lifecycle. Once a repository is more than a toy project, you should have a backup and recovery plan as mission-critical code could be lost in a data breach, account compromise, or accidental deletion. If you’re interested in getting serious about code backups, check out BackHub’s GitHub repository backup and recovery tool.
Ryan Westerberg">
