Prerequisites
- Primo server 3.3.0 or later and CLI 0.2.0 or later for guarded pushes
- Developer access to the hosted site
- Git and a team agreement about who pushes and publishes
Work on a change
1
Pull and record the starting point
Authenticate, pull the hosted workspace into a new folder, and initialize Git:Keep authentication credentials and database files out of Git. Commit workspace source files and the generated
.gitignore; handle .primo sync metadata as local state.2
Develop and review
Run
primo dev from the workspace root. Use files-author mode for code changes and --author cms for browser authoring. Avoid simultaneous file and CMS writes to the same content.Validate the affected site with primo validate -d sites/my-site, check its preview, and review the source diff in Git.3
Check before pushing
Save or commit your changes, then run
primo push --dry-run. Push only the intended site with primo push --only my-site when the shared library should remain untouched.A refused push means hosted data changed since the last sync. Preserve local work, pull, reconcile your changes, and push again. See Recover from a refused push.4
Review and publish
Open the hosted editor and inspect the saved changes. Choose Publish when the team is ready to update the public site. Other developers should pull the accepted server state before starting their next change.
Coordinate shared work
Agree on ownership of page types, block field definitions, and shared site content. A Git merge handles file changes; it does not update the sync baseline for a teammate’s machine. If that machine has no baseline for the hosted site, pull first and reapply its source changes. Use--force only for an intentional replacement of hosted changes. Primo saves a backup before a forced push, but the backup does not merge those changes into your local branch.
Library blocks are copied into sites. Updating the shared library does not patch existing site copies; coordinate those updates explicitly.