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
| State | git push / git pull | rbox |
|---|---|---|
| Commits, branches, tags | Yes, once pushed | Yes |
| Edited files not yet committed | No | Yes |
| Staged changes (the index) | No | Yes |
| New, untracked files | No | Yes, unless ignored |
| Current branch checkout | No; you switch by hand | Yes |
| Stash | No | Latest stash |
node_modules, .venv, build output | No (usually ignored) | No, by design |
.env and key files | No (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 pullFor 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 setupChoose 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 setupChoose 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 statusgit 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 statusreminds 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 statussays "rbox paused git sync there so nothing you did gets overwritten", andrbox git resolve <repo> show-meshows both sides before you pickkeep-mineortake-theirs.
What recovery can and can't do
- A file deleted by sync: goes to the local rbox trash first.
rbox trash listandrbox 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.tslists them;rbox restore src/app.ts@3puts one back. History is kept 30 days on Solo and 365 days on Pro. - Git state you chose to replace:
take-theirssaves 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.