{"id":1741,"date":"2025-05-29T08:54:00","date_gmt":"2025-05-29T08:54:00","guid":{"rendered":"https:\/\/blog.gitprotect.io\/?p=1741"},"modified":"2025-09-11T12:11:11","modified_gmt":"2025-09-11T12:11:11","slug":"git-restore-how-to-restore-deleted-files-in-a-git-repository","status":"publish","type":"post","link":"https:\/\/gitprotect.io\/blog\/git-restore-how-to-restore-deleted-files-in-a-git-repository\/","title":{"rendered":"Git Restore: How to Restore Deleted Files in a Git Repository?"},"content":{"rendered":"\n

Restoring deleted files with commands like ‘git restore’ might seem straightforward, but it can\u2019t serve as the foundation of your backup strategy. Let\u2019s explore why…<\/em><\/p>\n\n\n\n\n\n\n\n

Have you ever accidentally deleted a file from your DevOps environment, like GitHub, GitLab, Azure DevOps, or Bitbucket? Did you wonder 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<\/a> command works? Do you do backups of version control systems at all, and are you sure that your source code and multiple files in your repositories are safe? Do you use commands like git clone<\/a> and git restore to recover deleted files?<\/p>\n\n\n\n

They are critical questions, because while Git is a powerful distributed version control system, it was never designed to be a backup solution. Treating Git commands or custom scripts as a substitute for backup exposes organizations to unnecessary risks.<\/p>\n\n\n\n

Key insights:<\/strong>

\ud83d\udca1 Git commands like git restore, git checkout, and git clone are not backups. <\/strong>Yup, they can help recover deleted files or undo local changes, but they don\u2019t provide full, reliable protection for repositories or metadata.

\ud83d\udca1 DIY backup scripts are fragile and costly to maintain. <\/strong>Custom scripts require constant updates, documentation, and testing. Without dedicated resources, they often fail silently (without the possibility to restore accidentally deleted files, for example), leaving teams with a false sense of security.

\ud83d\udca1 A cloud service provider is not a backup. <\/strong>Storing code in GitHub, GitLab, Bitbucket, or Azure DevOps doesn\u2019t guarantee protection. Outages, ransomware, or accidental deletions can still wipe data or make it temporarily inaccessible.<\/p>\n\n\n\n

Backup approaches for ‘git restore’ deleted files<\/strong><\/strong><\/h2>\n\n\n\n

The problem discussed here is the lack of a standard for archiving distributed version control systems<\/a>. Let\u2019s assume, for example, that we have a local Git server adapted to our needs, and we want to back up this custom solution now, but how do we do it?<\/p>\n\n\n\n

You can, of course, archive the entire server, but it\u2019s a backup of everything, including the operating system and unnecessary or even potentially dangerous files with all the file content, applications, etc.<\/p>\n\n\n\n

So, how do you perform a Git backup<\/a> when you want to recover deleted files, and how do you take care of our repositories? We have built-in Git tools like git clone<\/em>, but how to deal with incremental archiving of individual repositories in such a system, and how to take care of changes made to multiple files?<\/p>\n\n\n\n

We can, of course, throw our repositories into a, for example, GitHub cloud, but it\u2019s also not a backup. We must remember that the \u201ccloud\u201d is someone else\u2019s computer and that someone may also have failures. Moreover, all service providers, like Microsoft, Atlassian, or GitLab, follow the Shared Responsibility Model<\/a>, which clearly defines that your account data is your responsibility. So, it’s you who needs to protect it… and back it up.<\/p>\n\n\n

\n
\"Get<\/a><\/figure><\/div>\n\n\n

Git is exciting and awesome, but it can be dangerous<\/strong><\/strong><\/h2>\n\n\n\n

Listing 1. How to create a PDF file with the ‘git clone’ command<\/strong><\/h3>\n\n\n\n

The git bundle<\/em> command is fascinating. It bundles a set of Git objects (even an entire repo) into one single file. Git bundle<\/em> is implemented in Git, and thanks to this git command line, you can treat that file as if it were a standard Git database. Let\u2019s look at Listing 1…<\/p>\n\n\n\n

git clone -mirror company.pdf kafej\nCloning into \u2018kafej\u2019...\nReceiving objects: 100% (221\/221), 111.21 KiB, done.\nResolving deltas: 100% (100\/100), done.\n$ cd kafej\n$ ls\ncompany.pdf company.tex\n<\/code><\/pre>\n\n\n\n
Listing 1. Creating a PDF file with ‘git clone’ command.<\/em><\/p>\n\n\n\n
Listing 2. How to create a valid PDF file with the ‘git bundle’ command<\/strong><\/h3>\n\n\n\n
The command git clone -mirror company.pdf company <\/em>will create a PDF file for us, which will be a Git repository. I mentioned it specifically because all the fun starts with the following command – git bundle<\/em>. It turns out that thanks to a minor modification in the \u201cbundle.c\u201d file, which consists of disabling the compression, we can prepare a PDF file from which Git will be able to clone a repo in your working directory. Let\u2019s look at Listing 2…<\/p>\n\n\n\n
$ git init\n$ git add kafej.pdf\n$ git commit kafej.pdf -m \u201cadded\u201d\n$ git bundle create company.pdf -all\n<\/code><\/pre>\n\n\n\n
Listing 2. Creating a valid PDF file with ‘git bundle’ command.<\/em><\/p>\n\n\n\n
Listing 3. How to restore files from the Git repository<\/strong><\/h3>\n\n\n\n
The file prepared in this way is intriguing, to say the least. Because thanks to the change introduced in a \u201cbundle.c\u201d  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. <\/p>\n\n\n\n
The git restore<\/em> command is also interesting. Hopefully, you are aware that this tool doesn\u2019t roll back the changes to the repository. We know the name can be confusing, but this comand tells git restore fileName<\/em> 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 the file from your repo, you can do that with the git checkout<\/em> command. Let\u2019s look at Listing 3…<\/p>\n\n\n\n
$ git rev-list -n 1 HEAD -- kafej.xml\n$ git checkout 9ad202d538c6ee6448e2c1ca1529f0e78edd3f86~1 -- kafej.xml\n<\/code><\/pre>\n\n\n\n
Listing 3. Restoring files from the Git repository.<\/p>\n\n\n\n
First, we need to use the git rev-list command to find the last commit and then use the checksum to restore the file (e.g, an accidentally deleted one) we are interested in using the git checkout command. Of course, restoring files is not difficult, and we can do it, but thanks to GitProtect backup and Disaster Recovery for DevOps tools, restoring files and your entire environment with GitHub, GitLab, Bitbucket, or Azure DevOps data is much faster. Moreover, you can have peace of mind that in any disaster scenario, you can easily retrieve missing files or lost files of your DevOps environment.<\/p>\n\n\n\n
Stop treating git clone like a backup<\/strong><\/h2>\n\n\n\n
Let\u2019s imagine a scenario in which we already have a script based on git clone or git bundle, and let\u2019s 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, everyone is aware of the dangers of such an approach.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Without well-prepared documentation, we have to consider big problems when, for example, the main person from such a team suddenly quits their job. However, without constantly checking whether the script is appropriately preparing backups, we can only assume that we do not have backups.<\/p>\n\n\n\n
In turn, the lack of updating the script for new versions, such as GIT, may result in incorrect execution of this script.<\/p>\n\n\n\n
So, it means a lot of work and much time…<\/p>\n\n\n\n
It’s estimated that IT teams might spend over 250 hours<\/a> a year on backup processes and still have no guarantee that they will be able to restore their data in case of a failure, like a service outage, internal organization’s downtime, ransomware attack, or you simply accidentally deleted a file and noticed that only after a few weeks (or even months!), etc.<\/p>\n\n\n\n
\u26a0\ufe0f Just to mention, according to the CISO’s Guide to DevOps Threats<\/a>, DevOps service providers faced:

GitHub<\/strong>: 26 major impact issues with 130+ hrs of disruption
Bitucket<\/strong>: 4 major impact issues with 4 hrs of disruption
GitLab<\/strong>: 7 major impact issues with 790+ hrs of disruption<\/p>\n\n\n
\n
\"DevOps<\/a><\/figure><\/div>\n\n\n
Backup solution wins over backup scripts<\/h3>\n\n\n\n
Third-party backup tools, like GitProtect, on the other hand, are comprehensive solutions that will always ensure that the repositories and all the related metadata (like deleted important files) are safe and available for recovery at any moment and from any point in time.<\/p>\n\n\n\n
For example, Zoop, one of the biggest fintech companies in Latin America, decided to back up its GitHub repositories with GitProtect backup and Disaster Recovery software after dealing with backups on its own for some time. First security engineers of the company manually backed up each repo, which needed a lot of manual maintenance, but then, after evaluating its tries, the organization decided on a third-party backup tool.<\/p>\n\n\n\n
\n
“When we need to restore a repository, GitPorotect brings speed, convinience and secuirty to this process,” <\/em><\/p>\n\n\n\n
– says Andre Esteves, Senior Security Analyst at Zoop (Read the full Case Study here<\/a>)<\/em><\/p>\n<\/blockquote>\n\n\n\n
However, behind the decision to opt for GitProtect was also the compliance requirements<\/a>. As the majority of compliance protocols, like NIS2, SOC 2, ISO 27001, etc., require organizations to be able to restore their data in case of a disaster, and, unfortunately, backup scripts can’t guarantee it.<\/p>\n\n\n
\n
\"Git<\/figure><\/div>\n\n\n
How to restore your deleted files with GitProtect<\/h2>\n\n\n\n
We have already mentioned that GitProtect isn\u2019t only an application or a tool for backup. It\u2019s a comprehensive product that gives you a reliable backup of your data without any additional application or script. So there is no need to trigger any git commands, like git restore, git checkout, or git clone, to back up or restore your deleted files on GitHub, Bitbucket, Azure DevOps, or GitLab.<\/p>\n\n\n\n
The data restore option is available directly in the management panel. Thus, all you need to do is choose the data you want to restore from (point-in-time restore) and decide on a location you want to restore deleted files to:<\/p>\n\n\n\n