Git with Dropbox: safe backup patterns and working-folder risks
Last updated: September 28, 2026
Short answer: you can store a Git repository in Dropbox, but syncing the same live working directory from multiple computers is risky. Dropbox copies files; it does not understand when Git is updating a branch, the index, refs, or repository objects as one operation.
Why Git repositories are different from normal folders
The visible source files are only part of a working repository. The hidden .git directory holds objects, refs, logs, the index, and other state that Git may update across several files during one command.
Dropbox sees those as unrelated file changes. If another machine edits the repository before every update arrives—or both machines write at once—the destination can contain a mixture of states Git never created.
The safest way to combine Git and Dropbox
Keep the active working repository outside Dropbox. Use a normal Git remote for commits, then place a deliberate, point-in-time bundle in Dropbox when you need an extra offline copy:
cd ~/code/project
git bundle create ~/Dropbox/git-backups/project.bundle --all
git bundle verify ~/Dropbox/git-backups/project.bundleThis avoids syncing a live .git directory while Git is writing to it. The bundle is one file, written once, so Dropbox can't catch it half-updated.
Recovering from the bundle
We tested the round trip on Git 2.53.0 on September 28, 2026, with a sample repository that had two branches, two stashes, a staged edit, an unstaged edit, and a new file:
git bundle verify ~/Dropbox/git-backups/project.bundle
# "The bundle records a complete history."
git clone ~/Dropbox/git-backups/project.bundle project-restored
cd project-restored
# Optional: recover the newest stash
git fetch ~/Dropbox/git-backups/project.bundle refs/stash:refs/stash
git stash apply refs/stashWhat came back, and what didn't:
- All branches and commits, with the same branch checked out.
- The newest stash—but only after the manual
fetch. A plain clone skips it, andgit stash liststays empty even after. - Not restored: the older stash, the staged edit, the unstaged edit, the new file, repository config, and hooks. A bundle protects Git history, not the work in progress around it.
After cloning, point the restored copy back at your real remote with git remote set-url origin <url>.
Can you put the working repository itself in Dropbox?
It may appear to work if only one computer ever touches the repository at a time and Dropbox fully settles before the next computer opens it. That is a workflow rule, not a safety guarantee. Background tools, editors, Git maintenance, and an accidentally opened laptop can all violate it.
Git's own documentation discourages naïvely copying a repository that might be written during the copy because the destination can be corrupted. A background file-sync client creates the same class of timing risk.
Git with Dropbox vs rbox
| Dropbox | rbox | |
|---|---|---|
| Repository awareness | .git is a folder of files | Branch, HEAD, index, and latest stash move as Git state |
| Local work on destination | Files may conflict | Files: incoming version wins, yours kept as a .conflict copy. Git: sync pauses until you choose |
| Dependencies and builds | Manual ignore rules on every computer | Skipped automatically |
| Project ignore files | Does not use .gitignore | Respects .gitignore; syncs .rboxignore |
| Encryption provider can access | Dropbox holds the service encryption keys | Files are encrypted on your device; rbox sees ciphertext |
A file conflict is not a Git conflict
Git conflicts occur inside a merge and preserve both sides for you to resolve. A Dropbox conflicted copy happens below Git, after two versions of an ordinary file collide. If that file lives inside .git, Git may not know how to interpret the result.
.gitignore doesn't configure Dropbox
Dropbox never reads .gitignore. A repo in Dropbox uploads node_modules, build output, and .env files unless you add matching rules to rules.dropboxignore—on every computer, because that file doesn't sync. See the Dropbox ignore-folder guide for the rules and for removing folders that were already uploaded.
The developer-native alternative
rbox passively syncs the whole working directory without treating Git internals as arbitrary files. Uncommitted source changes sync continuously; checkout state travels deliberately; and the receiving machine is checked for local work before anything is applied.
It also skips node_modules, virtual environments, caches, build output, and secrets by default. That saves storage and bandwidth without maintaining a separate Dropbox rules file on every machine.
rbox is sync with version history, not a replacement for every backup. Keep pushing to a Git remote, and keep an offline bundle if you need disaster recovery. The Git backup guide covers what each option restores.
Your checkout follows you safely. See how to sync code between two computers with rbox, or read the rbox vs Dropbox comparison if you're choosing a tool.
Official reference
Git documents the risk in its FAQ, "How do I sync a working tree across systems?", and what a bundle holds in the git-bundle reference.