Coming from Git

If you already think in Git, most of what you do every day has a counterpart here. The counterparts are not synonyms. Three of them differ in ways that change what you can express, and one of them — how a branch holds work — is the reason this model exists at all. This page gives you the mapping first, then the places where carrying a Git habit across will mislead you.

Command mapping

Five operations cover ordinary work. Read the right-hand column as a description of what happens, not as a translation of the left.

Two terms in that column are new. A Development Root is the single folder that holds all your active work; you declare it once with nexa root. A working context is one repository, branch and workspace materialised as a directory beneath that root. You do not choose where a working context lands the way you choose where to put a clone — it lands under the root, named after the repository.

Bringing work in is nexa get. It takes owner/repo for hosted work, or a path for a repository already on your disk:

$ nexa get acme/capture-demo

Ready: capture-demo
  repository: acme/capture-demo
  branch:     main
  workspace:  main
  path:       ~/Development/capture-demo

It does not take a URL. There is no address to copy out of a web page and no protocol to choose: owner/repo is the whole reference, and the directory created is named after the repository slug.

Recording and syncing are the other two. From the Development Root each names the project with -p, and neither names a destination, because the working context already knows its origin:

$ nexa record -p capture-demo -m "Add the feature note"

Created version 08692fb77a20
  workspace: main
  files:     1

Selected on branch main.

$ nexa sync -p capture-demo

Synchronized with Rinko Hub.

There is no origin in that output and no argument that could have named one. The single reconciliation step replaces the push-and-pull pair: it exchanges objects in both directions at once, so there is no ordering to get wrong and no state in which you have fetched but not merged.

Publishing is the fifth operation, and it collapses two Git steps into one. Where Git has you create an empty repository on the host and push to it as a second step, nexa publish — nexa publish -p my-project, for a project you have recorded a version of — creates the Rinko Hub repository, waits for it to be ready, and performs the initial synchronization itself. When it prints Published to Rinko Hub. the code is live; there is no follow-up to remember.

Where the models diverge

There is no staging area

Nothing corresponds to git add, and nothing corresponds to the index. A version is a whole tree — a complete, selectable state of a workspace — rather than a delta against its parent. nexa record captures the working tree as it stands.

To record only part of it, name the paths you want:

$ nexa record -m "Tidy the parser" src/

That records a subset by naming it at the moment of recording, which is the replacement for staging a subset first and committing second. The distinction matters beyond ergonomics: since a version is a whole tree, history is a sequence of states rather than a sequence of patches, and reading any single version never requires replaying the ones before it.

A branch holds candidates, not a pointer

This is the deepest divergence, and the reason the model exists. A Git branch is a pointer to one commit; moving it forward is the only thing it does. A Nexa branch holds a set of competing candidates — several versions offered as possible answers to the same problem, coexisting.

Selecting one does not delete the others. Selection is a mutable reference pointing at the candidate currently accepted; the alternatives remain addressable objects, and choosing differently later changes nothing about any of them.

Direct peer remotes are a separate capability

Nexa can connect two peers directly, without a hosted service in between: nexa remote, nexa push, nexa fetch and nexa serve are real, implemented commands, and a remote is an address paired with a device identity.

They are not part of hosted work on Rinko Hub, and reaching for them by analogy with git remote add is the mistake to avoid. Hosted work uses nexa get and nexa sync, which never name a remote. Treat the peer-to-peer surface as a distinct advanced capability you would adopt deliberately — for a repository shared between two machines with no hosted account involved — rather than as the layer underneath your everyday commands.

Habits to unlearn

nexa clone does not exist. It is not an alias, and there is no compatibility shim. The top-level command was removed outright, and typing it produces an unrecognized-subcommand error rather than a hint. What you want is nexa get.

Two smaller adjustments follow from the vocabulary. Say version, not commit: the word marks a different object, one that is a first-class alternative rather than a transient step. And there is no HEAD — the equivalent idea is the selected version, which is a property of the branch or workspace, never of the version itself.

If any of those terms are still doing unfamiliar work, the branches and workspaces concept page covers the candidate model in depth, and the glossary defines each term once.