How to back up a Git repository—including uncommitted 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 git@example.com: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 own documentation calls this a full backup of the repository's refs, then draws an important boundary: the bundle does not include your working tree, index, stash, per-repository configuration, or hooks.

The work Git backups miss

Traditional Git backups remain important. rbox complements them by protecting the live work between commits—the part most likely to exist only on one machine.

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 files. It moves branch, HEAD, index, and stash state as an explicit Git bundle and applies it only when the receiving repository has no local divergence. If another machine has local work, rbox waits instead of overwriting it.

Dependencies and build output stay local, version history does not count against your storage quota, and everything is encrypted before it leaves your device.

Protect the work between commits. Install rbox for passive, encrypted workspace sync, or learn what changes when you try to use Git with Dropbox.

Official references

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