--- title: "Version control" description: "A world's history, branches and reviews are handled by ZeroMind — Zero's own version control system. If you have used git, the model will feel familiar: the verbs carry the same names and mean the…" section: "Core" slug: "core-version-control" canonical: "https://origozero.ai/docs/core-version-control" updated: "2026-09-05T16:41:46.569119640+00:00" --- # Version control | If you know git as | In a world it is | |---|---| | Repository | A world | | Working tree | Your live session | | Forge | ZeroMind | | Fork | A world forked from another | | add / commit / push | the `zm` tools of the same names | | branch / checkout / merge | the `zm` tools of the same names | | log / show / diff / status | the `zm` tools of the same names | | Pull request | `prOpen`, `prView`, `prMerge` | These run in the engine shell: ```bash zero zm # every versioning tool zero zm --help # one tool's arguments and types ``` That help comes from the live registry, so it is never out of date. Two things work differently from a checkout on your own disk, and both follow from a world being a **shared, live session**. **Writes are durable immediately.** There is no save step, and collaborators see your edits as you make them. Commit and push are about history and publishing, not persistence — `core/development` covers that split. **A branch is per-connected-client.** Checking one out changes *your* view; everyone else stays where they are. ## Branches — several people, one world A branch gives you your own working tree inside the same world, so two people or two agents can work without overwriting each other. Create a branch and you stay where you are; checkout is the step that moves you, and it returns once the branch's content has landed, so whatever you run next already targets it. Commit as normal, then merge the branch back. A clean merge lands a two-parent merge commit. When both sides changed the same path the merge stops and `status` lists the unmerged paths; resolve each file, then add and commit — that commit records the merge. Merge also takes an abort, which restores the pre-merge tree exactly. ## Pull requests A pull request proposes the work on one `(world, branch)` pair to another. Both ends are addressable, which is what lets a fork propose work to the world it came from. A request **lives in, and is numbered by, the world it targets** — exactly as a forge numbers pull requests on the upstream repository. So a fork's outgoing requests are listed on the world they were opened against, not on the fork. **Read a request before merging it.** `prList` gives you the records — who, when, which branches. `prView` re-analyses one against the current branch heads and tells you what it actually changes: its mergeability verdict, how many paths conflict, and the diff — every path added, modified or deleted. Merging without viewing is merging blind. ## Forks — contributing to someone else's world Forking a world gives you your own copy to work in. Work in your fork exactly as you would in any world. When the change is ready, **push it** — a pull request references published commits, so work sitting only in your session is not part of one. Then open the request, naming the world you are proposing to. The same call with no target world proposes within the world you are in, which is the ordinary branch-to-branch request. Every leg — source world, source branch, target world, target branch — is addressable, so the reverse direction is a request too: propose the origin's branch into your fork to take its later work, and merge that in your fork. That is how a fork stays current with what it forked from. ## Where to go next - `core/development` — commit versus push, what players run, and how live scene edits reach a commit - `core/worlds` — the world model itself - `zero zm --help` in the engine shell — arguments and types for any verb above. `zm ` reaches the same tool by the same dispatcher, so the two spellings are one surface.