Picture this: it’s a Friday afternoon. An engineer pushes a bad merge, a CI pipeline misfires, and within twenty minutes the main branch is a mess of deleted pull requests, rewritten workflow files, and orphaned issues. The VP of Engineering walks over, calm. “We’re fine, right? Every developer has a local clone of the repo.”
That answer is half true. It’s also why so many DevOps teams walk into a 2 AM restore with the wrong expectations.
git clone is a command that copies a remote git repository to your local machine. It pulls the git object database, which is the part most engineers think of as “the code.” That includes commit history, branches as remote-tracking refs (pointers to the remote server’s branches), tags, and HEAD. A clone captures the working tree and the history attached to it, but that’s all it captures.
It does not capture Issues, Pull Requests, GitHub Actions workflows or Secrets, branch protection rules, CODEOWNERS (the file that maps directories to reviewers), webhooks, releases, environments, teams, or any org-level configuration. git clone --mirror, the flag that promises to grab “all refs,” captures those refs in a form that cannot be pushed to a different server. The mirror-as-backup argument falls apart the moment you need to re-push into a fresh org.
A photograph of a house is not the house.
The metadata layer is where the bad actor lives
The “git is distributed, so we’re backed up” argument lives in almost every DevOps deal. It’s a reasonable thing to say about source code. It’s an incorrect thing to say about the platform wrapped around it.
Most breaches, 68% of them, involve a non-malicious human element, a person making an error or falling for social engineering (Verizon 2024 Data Breach Investigations Report). 87% of IT professionals reported SaaS data loss in 2024, with malicious deletions as the leading cause (Kaseya, 2025 State of Backup and Recovery Report, n=3,000+).
And the attackers know where the backups live. In 94% of ransomware attacks, they tried to compromise the victim’s backups during the attack itself (Sophos, 2024 State of Ransomware).
The specifics of the platform are where the exposure shows up.
What each platform actually holds
Platform-specific details below are drawn from each vendor’s own public documentation (linked inline).
On GitHub, beyond the code, the SaaS layer holds Issues and Pull Requests with their comment threads and review history, Actions workflows and the Secrets that feed them, branch protection rules, CODEOWNERS, webhooks, releases, environments, teams, and org-level configuration. GitHub’s API documentation is explicit on the Secrets point: they are write-only from the API perspective. You can create and update them with encrypted values through LibSodium, but you can never retrieve the decrypted values back out. A git clone --mirror does not give you any of that, and the mirrored refs cannot be pushed to a different server to rebuild.
On Azure DevOps, the repo is only one service inside a project. The project also holds Pipelines (YAML and Classic) plus the Library that stores Variable Groups and Secure Files (Microsoft Learn, “Manage variable groups”). Variable Groups can mark values as secret, at which point the stored values are hidden and cannot be read back through the UI or CLI. A git clone does not capture those service-layer objects.
On Bitbucket Cloud, a workspace holds more than repositories. It holds Pipelines configuration and repository variables, deployment environments with their own variables, branch restrictions, and workspace-level access controls (Atlassian Support, Bitbucket Cloud “Variables and secrets”). Workspace access tokens and repository access keys live at the workspace and repository level, not inside git history. A git clone preserves none of that surface area.
Across all three, the pattern is the same. git clone preserves code and git history. Platforms also hold Pipelines, service tokens, deployment configuration, branch policies, and workspace- or org-level permissions that git clone cannot capture.
Three restore scenarios where a repo-only backup fails
The admin departure. Your senior DevOps engineer leaves. On the way out, someone rotates the Actions Secrets (or Azure DevOps Variable Group secrets, or Bitbucket Pipelines variables) as a precaution. The new admin rebuilds them from scratch. If the outgoing admin didn’t document them, work stops until someone digs through old Slack threads and vendor portals. A clone of the repo does not help.
The production rollback. A bad deploy goes live and the team rolls back to a release tagged two weeks ago. The code is there, but the branch protection rules as they existed at that moment are not. The release assets as they existed at that moment may not be. The PR discussion that approved the release is fine, but the webhook or deployment environment configuration that fired at deploy time is a current-state snapshot, not a point-in-time reproduction.
The social engineering hit. An engineer falls for a phishing email. Credentials are compromised. An attacker deletes a batch of pull requests and issues on the way out. A git clone on a laptop preserves the code. It does not preserve the comment threads, the review approvals, or the audit chain tied to those PRs. When the compliance team asks for the record of who approved what, there is no record.
Most restore stories DevOps teams tell each other are not “we lost the code.” They are “we lost the rules around the code.” Branch protections, required reviewers, CODEOWNERS assignments, deployment environment guards, pipeline approvals. The governance layer is where the weeks of rebuild work live.
How AI agents widen the gap
Rewind does not have AI products. Rewind’s backup and restore product protects your SaaS data from errors introduced by your own AI agents, automations, and AI-assisted workflows. An agent with write access to Actions workflows or pipeline configuration can modify thousands of lines in a single execution. Item-level restore, the ability to recover individual items like a single PR or a single workflow file without affecting the rest of the repo, is the response shape that matches that blast radius. That’s non-destructive recovery.
Where Rewind fits
Rewind is a SaaS resilience platform built on independent architecture, a platform and not a plugin, so your data stays accessible even if the SaaS vendor is compromised. The engineering team is in-house in Canada. Integrations are built and maintained in-house, not outsourced to third-party connectors. The core product has more than 16 native integrations, and across core, IdP, and secondary integrations, Rewind supports more than 20 platforms. More than 25,000 organizations trust Rewind.
“Rewind doesn’t just give us a full backup of the codebase with just a few clicks; it also gives us a business continuity plan in the event of the worst-case scenario,” says Uttej Badwane, Senior Security Engineer at Carta.
“We knew Atlassian provides limited data backup coverage, but that doesn’t extend to backup of account-level data in GitHub and Jira,” says Eran Polak, R&D Manager at Matics.
If you run a GitHub Org, an Azure DevOps project, or a Bitbucket workspace, walk your current backup posture against the list above. Score each row as covered, partially covered, or not covered. Then send the result to your VP of Engineering with one line: our DevOps backup covers the code, and here is what it does not cover.
Learn more about Rewind for GitHub at rewind.com/products/backups/github.
Rewind">
