Browse documentation
Repositories and Changes
Git command comparison
Map everyday Git tasks to Composal-native source-control workflows.
On this page
The essential shift
- No staging area. Edit files directly; Composal snapshots them into the current change.
- Changes compose naturally. Use
com new,com rebase, andcom squashinstead 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 | Composal |
|---|---|---|
| Clone a repository | git clone <url> | com clone <org>/<repo> |
| Check the working copy | git status | com status |
| See a diff | git diff HEAD | com diff |
| Start related work | git switch -c topic <target> | com new main -m "message" |
| Inspect history | git log --oneline --graph | com log -r ::@ |
| Amend the previous change | git commit --amend | com squash |
| Recover a repository operation | git reflog | com undo |
In a Composal-native checkout, do not run git add: there is no staging area. Use com restore <paths> to discard selected file changes and com abandon to remove an entire change.
Publish and review
For an explicit target publication, finalize a change and move the target bookmark to it.
com commit -m "Describe the completed change"
com bookmark set main -r @-
com push main
For reviewable work, submit independent changes and land by change number.
com submit -r 'main..@' --target main
com sync --target main
com land #42
com pull refreshes hosted state while leaving your files in place. com pull --update moves the working copy when it is safe; com pull --rebase moves current changes onto the selected target.
When to use Composal Git compatibility
Use com git when you are deliberately operating against a Git remote or consuming a Git-compatible path. Use com clone, com status, com commit, and com push in a Composal-native checkout. See source control for the full model and remote Git sync for external providers.