Git command comparison

Map everyday Git tasks to Vex-native source-control workflows.

On this page

The essential shift

No staging area. Edit files directly; Vex snapshots them into the current change.
Changes compose naturally. Use vex new, vex rebase, and vex squash instead of manufacturing a branch for every step.
Publishing is explicit. A bookmark names the target you publish; review and landing are separate workflow steps.

Everyday work

Task	Git	Vex
Clone a repository	`git clone <url>`	`vex clone <org>/<repo>`
Check the working copy	`git status`	`vex status`
See a diff	`git diff HEAD`	`vex diff`
Start related work	`git switch -c topic <target>`	`vex new main -m "message"`
Inspect history	`git log --oneline --graph`	`vex log -r ::@`
Amend the previous change	`git commit --amend`	`vex squash`
Recover a repository operation	`git reflog`	`vex undo`

In a Vex-native checkout, do not run git add: there is no staging area. Use vex restore <paths> to discard selected file changes and vex abandon to remove an entire change.

Publish and review

For an explicit target publication, finalize a change and move the target bookmark to it.

Terminal

vex commit -m "Describe the completed change"
vex bookmark set main -r @-
vex push main

For reviewable work, submit independent changes and land by change number.

Terminal

vex submit -r 'main..@' --target main
vex sync --target main
vex land #42

vex pull refreshes hosted state while leaving your files in place. vex pull --update moves the working copy when it is safe; vex pull --rebase moves current changes onto the selected target.

When to use Vex Git compatibility

Use vex git when you are deliberately operating against a Git remote or consuming a Git-compatible path. Use vex clone, vex status, vex commit, and vex push in a Vex-native checkout. See source control for the full model and remote Git sync for external providers.