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:
zero zm # every versioning tool
zero zm <tool> --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 commitcore/worlds— the world model itselfzero zm <tool> --helpin the engine shell — arguments and types for any verb above.zm <tool>reaches the same tool by the same dispatcher, so the two spellings are one surface.