Syncing your work
How your project moves between your computer, the cloud, and the machine that runs it, and the one command that keeps all three in agreement.
Your project exists in more than one place. There is the copy on your computer, the one you edit with the CLI or the Web IDE. There is the copy in the cloud, which is the version the platform stores for you. And there is the copy on whatever machine actually runs your work, either the cloud simulator or a workstation wired to real arms.
The cloud copy is the hub. Everything travels through it. Your laptop never talks to the lab machine directly, and the lab machine never reads your local files. This has one consequence worth fixing in your head early: nothing you save locally reaches the simulator or the robot until you push it. A skill you edited five minutes ago and did not sync is, as far as a run is concerned, the old skill. If a change you are sure you made does not show up in a run, an unsynced working tree is the first thing to check.
Sync is what moves work between those copies. The model is deliberately close to Git, because the problems are the same ones: you have local edits, the cloud has moved on since you last looked, and something has to reconcile the two. Your project has a working tree (the files on disk), commits (snapshots you have recorded), and a pointer to where the cloud was the last time you talked to it.
The one command
You do not have to drive that machinery by hand. In normal use, one command covers it:
zeon sync -m "add a pour skill"That commits your current changes, pulls whatever is in the cloud, merges the two, and pushes the result. The ordering matters. Because zeon sync always pulls before it pushes, it sidesteps the failure people hit most often, which is a push rejected because someone (or you, from another machine) changed the cloud since you last pulled. Run it whenever you finish a piece of work, and run it before you start a run somewhere else.
zeon sync stops only when the same file was edited both locally and in the cloud in a way it cannot reconcile. It tells you which files, and you finish with zeon sync --continue after editing them, or back out with zeon sync --abort, which leaves your local changes intact.
Get in the habit of running
zeon statusbefore you sync. It shows what you are about to send, which is a cheap way to catch a file you did not mean to change.
Everyday commands
| Command | What it does |
|---|---|
zeon status | Lists added, modified, deleted, and unmerged files against your last commit, plus where the cloud pointer sits. Add --json for machine-readable output. See Working tree commands. |
zeon diff | Shows the line-by-line changes in your working tree. Pass one or more paths to narrow it. See Working tree commands. |
zeon sync -m "message" | Commit, pull, merge, push. The default way to move work. See zeon sync. |
The finer-grained commands (commit, push, pull, log, checkout, and reset) exist too, and they are worth knowing when you want to record a snapshot without publishing it, or to look at history. They are documented separately so this page stays about the common path.
The pages in this section
The model underneath: working tree, commits, the cloud pointer, and what a merge actually does to your files.
The command in full, including --continue and --abort, and what each line of its output means.
status, diff, commit, push, pull, log, checkout, and reset, one at a time.
What to do when a sync stops with a conflict, and how to get moving again without losing work.
If you have never synced a project before, read How sync works first. If you are here because a sync stopped and told you to resolve something, skip straight to Resolving diverged from cloud.
Updated 3 days ago