Back up and restore a Git repository—including unfinished work

Short answer: use a remote, mirror clone, or git bundle to back up committed Git history. Then protect your working directory separately. A normal Git backup does not include uncommitted files, the index, or the rest of your live checkout.

What does “back up a Git repository” mean?

A working repository contains three different kinds of data:

• Git history: commits, branches, tags, and other refs.
• Your current work: modified and untracked files, staged changes in the index, and stashes.
• Hosting data: pull requests, issues, releases, settings, and other metadata stored by GitHub or another forge.

No single Git command covers all three. Decide what you need to recover before choosing a backup method.

Option 1: push commits to another remote

A second remote is the simplest protection for committed work. It gives you another copy of the branches and tags you push, but it only protects work after you commit and push it.

git remote add backup [email protected]:you/project.git
git push backup --all
git push backup --tags

This is useful redundancy, not a complete backup of your laptop's current checkout. An unfinished file that has never been committed is not part of a push.

Option 2: create a mirror clone

A mirror clone copies all refs from a repository and is useful for backing up a hosted remote or moving it to another server.

git clone --mirror https://github.com/you/project.git project-backup.git

Refresh the mirror later with git remote update. This still mirrors the repository you cloned—not your uncommitted working directory, and not GitHub issues or pull requests.

Option 3: make a portable Git bundle

Git bundles package repository objects and refs into one file that can be stored offline or copied elsewhere.

git bundle create project.bundle --all
git bundle verify project.bundle

# Recover into a new directory
git clone project.bundle recovered-project

Git's documentation warns that a bundle does not carry your working tree or index. Stashes are subtler, as the drill below shows.

Restore drill: what actually comes back

A backup you've never restored is a guess. We ran this on Git 2.53.0 on September 28, 2026. The repository had two branches, two stashes, a staged edit, an unstaged edit, and a new file:

$ git status --short
M  app.txt          # staged
 M notes.txt        # unstaged
?? untracked.txt    # new file
$ git stash list
stash@{0}: On feature: second
stash@{1}: On feature: first

$ git bundle create ../project.bundle --all
$ git bundle list-heads ../project.bundle
80c7726… refs/heads/feature
2e5ad81… refs/heads/main
d97eee7… refs/stash
80c7726… HEAD

The bundle does include refs/stash. Then we restored it into a clean directory:

$ git clone project.bundle recovered && cd recovered
$ git status --short
(nothing — staged, unstaged, and new files are gone)
$ git stash list
(nothing — clone does not copy refs/stash)

# Fetch the stash ref by hand, then apply it
$ git fetch ../project.bundle refs/stash:refs/stash
$ git stash apply refs/stash   # restores "second"

Run the same check on your own backups: restore into an empty folder, then compare git branch -a, git status, and git stash list against the original.

Four jobs, four tools

The work Git backups miss

Sync alone is not a backup: a deletion on one machine is meant to reach the others. What makes it recoverable is retained history, which is next.

Why not copy the whole repository folder?

A file-level copy can catch the working tree, but copying a live .git directory is not transaction-aware. Git warns that a naïve recursive copy can be corrupted if the repository is written while the copy is running.

Generic file sync has the same blind spot: it sees independent files, not a branch, index, and stash that belong together. Two machines changing the same repository can produce an incoherent destination.

Back up the working tree automatically

rbox continuously syncs the developer workspace, including uncommitted and untracked files. It moves branch, HEAD, index, and latest stash as an encrypted Git bundle, and applies it only when the receiving repository has no work of its own. If it does, rbox pauses Git sync for that repo instead of overwriting it.

How restore works in rbox

Deletions sync: delete a file on one machine and it is removed on the others. Two things let you undo that.

# Files rbox removed on this machine go to a local trash first
rbox trash list
rbox trash restore src/app.ts

# Older synced versions of a file
rbox versions src/app.ts
rbox restore src/app.ts@3
rbox push                    # the restore is a local change until you sync it

Version history is kept 30 days on Solo and 365 days on Pro, and does not count against your storage. The local trash keeps up to 30 days or 2 GiB by default. Restores are per file; there is no one-command rollback of a whole workspace, and rbox doesn't back up GitHub issues or pull requests. Keep an offline bundle or mirror for disaster recovery.

Protect the work between commits. Install rbox for passive, encrypted workspace sync, or learn how to sync code between two computers. Using Dropbox or Syncthing today? Read Git with Dropbox or Syncthing and Git.

Official references

See the official Git bundle documentation and GitHub's repository-backup guide for current commands and limitations.