rrbox
How it worksAboutPricingDocsChangelog
Sign inGet started
← Back to home

Sync code between two computers, including unfinished work

Last updated: September 28, 2026

Short answer: Git moves your commits. Everything between commits—edited files, staged changes, new files, stashes—stays on the computer where you left it. You can carry it across by hand with Git, or let a workspace sync tool like rbox move it for you. Either way, install dependencies on each machine instead of syncing them.

What Git already moves, and what it leaves behind

Stategit push / git pullrbox
Commits, branches, tagsYes, once pushedYes
Edited files not yet committedNoYes
Staged changes (the index)NoYes
New, untracked filesNoYes, unless ignored
Current branch checkoutNo; you switch by handYes
StashNoLatest stash
node_modules, .venv, build outputNo (usually ignored)No, by design
.env and key filesNo (usually ignored)No by default; opt in with .rboxignore

Option 1: Git only

If all your work is committed, this is all you need:

# laptop, before you leave
git push

# desktop
git pull

For unfinished work, Git 2.51 and later can export stashes to a branch. This carries unstaged edits, staged edits, and new files:

# laptop
git stash push --include-untracked -m "handoff"
git stash export --to-ref refs/heads/stashes
git push origin stashes

# desktop (clean working tree)
git fetch origin +stashes:stashes
git stash import stashes
git stash apply --index stash@{0}

We tested this on Git 2.53.0 and the desktop ended up with the same staged, unstaged, and untracked files as the laptop. The full run, including what happens when the desktop already has edits, is in Syncthing and Git.

Costs: you must remember every time, the desktop must be clean first, and your unfinished work sits in a branch on your Git host until you delete it.

Option 2: rbox keeps the workspace in sync

rbox runs in the background on each machine. Working files sync as encrypted files. Git state—branch, HEAD, index, latest stash, and a half-done rebase or merge—moves as an encrypted git bundle. It supports macOS on Apple silicon and Linux on x64 or ARM64.

First machine

curl -fsSL https://rbox.to/install.sh | sh
cd ~/code/myapp
rbox setup

Choose Create a new account, save your recovery phrase, then Create a new workspace from a directory. When setup finishes, pick Set up another machine now to get a one-time pairing token. You can also run rbox pair later.

Second machine

curl -fsSL https://rbox.to/install.sh | sh
rbox setup

Choose Log into an existing account, paste the token, then Sync an existing workspace and pick an empty local folder. Choose to start background sync now and on boot. The docs walk through each prompt.

Check the handoff

Run the same two commands on both machines:

git status
rbox status

git status should show the same branch and the same staged, unstaged, and untracked files on both. rbox status shows whether sync is running and flags anything that needs you.

Install dependencies on each machine

rbox skips node_modules, .venv, target/, dist/, build/, caches, and similar folders on purpose. They are large, they rebuild from your lock files, and some contain binaries for one OS or CPU. A Mac's native modules won't run on Linux anyway. After the first sync, run your usual npm install, uv sync, or cargo build on the second machine. Lock files do sync, so both machines stay on the same versions.

Secrets like .env, *.pem, and *.key are also skipped by default. Templates such as .env.example still sync. If you do want a secret on both machines, opt in with rbox ignore '!.env'; it is encrypted on your device before upload.

If the network drops

Nothing half-finished is shown to your other machine. rbox publishes a new version only after all of its uploads are recorded. Failed requests are retried, the background process reconnects on its own, and large files resume from the parts already uploaded. You don't need to do anything; if you run a command by hand and it fails, it's safe to re-run.

If the second machine already has edits

This is where syncing code differs from syncing documents.

  • Same file edited on both machines: rbox writes the incoming version and keeps yours next to it as name.<device>.<time>.conflict.ext. rbox status reminds you until you clean them up.
  • Git state differs (uncommitted work, local-only commits, a stash, or a half-done rebase): rbox pauses Git sync for that repo and leaves your local Git state untouched. rbox status says "rbox paused git sync there so nothing you did gets overwritten", and rbox git resolve <repo> show-me shows both sides before you pick keep-mine or take-theirs.

What recovery can and can't do

  • A file deleted by sync: goes to the local rbox trash first. rbox trash list and rbox trash restore <path> bring it back (kept up to 30 days or 2 GiB by default).
  • An older version of a file: rbox versions src/app.ts lists them; rbox restore src/app.ts@3 puts one back. History is kept 30 days on Solo and 365 days on Pro.
  • Git state you chose to replace: take-theirs saves the old state in .rbox/git-quarantine/ first.
  • Not covered: there is no one-command restore of a whole workspace to a past date, and rbox does not back up GitHub issues or pull requests. Keep pushing to a Git remote too. See the Git backup guide.

Connect your second machine. Install rbox, run rbox setup, and pick up where you left off. Your first subscription includes 14 days free (pricing). Coming from another tool? Compare Syncthing or Dropbox.

rrbox

Dropbox for your code.

PricingSign inInstallDocsDevelopersContactAboutChangelogSecurityGit backupGit + DropboxDropbox ignore rulesvs Dropboxvs Syncthingvs Resilio Syncvs FreeFileSyncPrivacyTerms

© 2026 rbox · Built on Cloudflare