Git Restore: How to Restore Deleted Files in a Git Repository?
Last Updated on March 4, 2024
Have you ever wondered how to restore deleted files from your repository, how to check if such a restore will work properly or how to track file changes in the backups themselves? Have you wondered how the git restore command works? Do you do backups of version control systems at all, and are you sure that your codes and files in your repositories are safe? Do you use commands like git clone and git restore?
Backup approaches for git restore
The problem discussed on the pages of the GitProtect blog for some time is the lack of a standard for archiving distributed version control systems. Let’s assume, for example, that we have a local Git server adapted to our needs, and we want to backup this custom solution now, but how to do it? You can, of course, archive the entire server, but it’s a backup of everything, including the operating system and unnecessary or even potentially dangerous files, applications, etc. So, how to perform a Git backup and how to take care of files in our repositories? We have built-in Git tools like git clone, but how to deal with incremental archiving of individual repositories in such a system and how to take care of changes made to files. We can, of course, throw our repositories into a, for example, GitHub cloud, but it’s also not a backup. We must remember that the “cloud” is someone else’s computer and that someone may also have failures. GitProtect will answer all these questions.
Git is exciting and awesome but can be dangerous
The git bundle command is fascinating. It bundles a set of Git objects (even an entire repository) into one single file. Git bundle is implemented in Git, and thanks to that, Git allows you to treat that file as if it were a standard Git database. Let’s look at Listing 1.
git clone -mirror company.pdf kafej
Cloning into ‘kafej’...
Receiving objects: 100% (221/221), 111.21 KiB, done.
Resolving deltas: 100% (100/100), done.
$ cd kafej
$ ls
company.pdf company.tex
Listing 1. Creating a PDF file with git clone command.
The command git clone -mirror company.pdf company will create a PDF file for us, which will be a Git repository. I mentioned it specifically because all the fun starts with the git bundle command. It turns out that thanks to a minor modification in the “bundle.c” file, which consists of disabling the compression, we can prepare a PDF file from which Git will be able to clone a repo. Let’s look at Listing2.
$ git init
$ git add kafej.pdf
$ git commit kafej.pdf -m “added”
$ git bundle create company.pdf -all
Listing 2. Creating a valid PDF file with git bundle command.
The file prepared in this way is intriguing, to say the least. Because thanks to the change introduced in a “bundle.c” file, it will be a valid pdf file, and in principle, most PDF readers will open it like a regular one. It offers many possibilities, good and bad ones.
The git restore command is also interesting. Hopefully, you are aware that this tool doesn’t roll back the changes to the repository. I know the name can be confusing, but git restore fileName will only remove from this file your local changes. So, thanks to this command, we can undo local changes, but only on our disk. In fact, if you need to restore a file from your repository, you can do that with the git checkout command. Let’s look at Listing3.
$ git rev-list -n 1 HEAD -- kafej.xml
$ git checkout 9ad202d538c6ee6448e2c1ca1529f0e78edd3f86~1 -- kafej.xml
Listing 3. Restore file from Git repository.
First, we need to use the git rev-list command to find the last commit and then use the checksum to restore the file we are interested in using the git checkout command. Of course, it’s not difficult and we can do it, but thanks to Xopero One Backup you will be able to easily and intuitively manage the history of files in one place.
How secure are your repos and metadata? Don’t push luck – secure your code with the first professional GitHub, Bitbucket, and GitLab backup.
Let’s consider it again
Let’s imagine a scenario in which we already have a script based on git clone or git bundle, and let’s even assume that we are sure that such an internal solution is sufficient for us. I hope that based on the above proof-of-concept, however, everyone is aware of the dangers of such an approach. Custom scripts prepared by an internal team inside the company work well. Still, we must have a group of people who will constantly update such a script, check its operation, and refresh the documentation. Only then can we be tempted to say that we are relatively safe. Without well-prepared documentation, we have to consider big problems when, for example, the main person from such a team suddenly quits his job. However, without constantly checking whether the script is appropriately preparing backups, we can only assume that we do not have backups. In turn, the lack of updating the script for new versions, such as GIT, may result in incorrect execution of this script. GitProtect, on the other hand, is a comprehensive solution that will always ensure that the repositories are safe and available for recovery at any time.
I have already mentioned that GitProtect isn’t only an application or a tool. It’s a comprehensive product that gives you a reliable backup of your data without any additional application or script. The data restore option is available directly in the management panel. Choose data you want to restore and decide whether it should be restored to:
- a new repository,
- crossover – to another hosting platform. It enables fast and easy migration – you can restore your Bitbucket repository to GitHub or GitLab repo and, conversely,
- your local service/device.
It’s also worth mentioning that you get the option to restore only one repository or many repositories, but also all or selected metadata from a given backup.
