vers commit. Commits have a content-addressable id (e.g. c123456789abcdef) that uniquely identifies that exact state.
Commits are the currency of sharing, reuse, and reproducibility in Vers. Everything that “starts from somewhere” starts from a commit.
What a commit captures
In practice: if your work is in memory or on disk, it’s in the commit. If it depends on the outside world, you’ll need to re-establish that.
Creating a commit
Restoring from a commit
Commits vs branches vs forks
These words get muddled — a quick disambiguation:
Branches always produce a running VM. Commits always produce a frozen state. Restores always produce a running VM from a frozen state.
Lifetime and deletion
Commits persist until you explicitly delete them withvers commit delete. They survive:
- The deletion of the VM that produced them
- The deletion of the child VMs they created
- Your CLI logging out and back in
Tagging commits
Commit ids are long and unmemorable. Tags fix that:vers tag update — and cheap. Deleting a tag doesn’t touch the commit it pointed at.
Anywhere a commit id is accepted (vers run-commit, vers branch, vers build’s FROM), you can pass a tag name instead.
Repositories
For structured naming, tags can live inside repositories:my-app:latest, my-app:v1.2, etc. A repo is a namespace for a related group of commits. Repos can be public (other orgs can fork them) or private.
See vers repo for the full workflow; most users can get away with plain tags until they need the structure.
A typical workflow
1
Prepare
Boot a VM, install dependencies, configure things.
2
Freeze
3
Fan out
Every future VM starts from this known-good base.
See also
- VMs — what you commit from
- vers commit, vers run-commit, vers tag
- Dockerfile support — build commits declaratively