Every save in Sitepins is a decision about Git: commit now, commit as a draft, or don’t commit at all. The split button in the editor header covers all three.
The Save Button
The main button changes label based on the file:
| Label | Means |
|---|---|
| Publish | The default — commit the file to your branch |
| Draft | The file’s frontmatter has draft: true, so committing keeps it a draft |
| Save | You’re working from a saved draft that hasn’t been committed yet |
| Saved | Nothing has changed since your last save |
The chevron next to it opens the other actions.
The Four Actions
Publish Now
Commits the file to the current branch. Your host rebuilds, and the change is live.
Push as Draft
Commits the file with the draft flag set. The change is in Git — it’s just marked as a draft so your site generator excludes it from the build.
Use this when you want the work backed up and visible to teammates in the repository, but not published.
Save as Draft
Pro plan. Available on Pro and above, during the free trial, and in every self-hosted install.
Saves your work to Sitepins only. Nothing is committed, nothing is pushed, no build is triggered. Reopen the file later — from any device — and your draft is waiting.
Use this for work in progress you don’t want in the repository yet.
These two are easy to confuse, and the names changed. Save as Draft used to mean “commit with the draft flag”. That behaviour is now called Push as Draft. Save as Draft now means a Sitepins-only save with no Git push at all.
Discard Saved
Appears only when you have a saved draft. Deletes it and returns the file to whatever is in Git.
When Git Moves Under a Saved Draft
If someone commits to the same file while you have an uncommitted draft, Sitepins notices on reopen and shows a draft conflict dialog with a line-by-line diff of the two versions.
You choose:
- Use your draft — keep editing your version
- Use the Git version — discard your draft and start from what’s in the repository
Nothing is merged automatically, and nothing is overwritten without you picking.
Commit Messages
By default, Sitepins writes the commit message for you — “Update file”, “Rename old-name to new-name”, “Create new blog”, “Delete file”, and so on.
Pro plan. Custom commit messages are available on Pro and above, during the free trial, and in every self-hosted install.
Turn on Custom Commit Messages in Project Settings → Configure and a dialog appears before each commit with:
- Commit message (required)
- Extended description (optional)
Turn it on if you follow a commit convention. Leave it off for a faster loop.
Who the commit is attributed to is a separate setting — see Preferences.
Required Fields
If your folder has a schema with required fields, Sitepins validates them before committing. Empty required fields — including ones nested inside objects and arrays — block the save and are called out so you can fill them in.
Renaming Through the SEO Panel
Editing the slug in the SEO panel doesn’t rename the file immediately. It stages a rename that happens as part of your next commit, so the content change and the rename land together. After the commit you’re redirected to the file’s new URL.
Discarding Changes
The Reset button in the editor header discards your unsaved edits and returns the file to its last saved state. You’ll be asked to confirm.
Reset is not a Git operation — it only affects what’s in the editor. To undo something already committed, see Version History.
If you try to navigate away with unsaved changes, Sitepins stops you and asks first.
Build Status
Pro plan. Available on Pro and above, during the free trial, and in every self-hosted install.
After a commit, a status badge in the editor header tracks the resulting build:
| Status | Meaning |
|---|---|
| Building… | A build is running |
| Pending | Queued, not started |
| Success | Build passed |
| Failed | Build failed — check your host’s logs |
| Inactive | The check is registered but not running |
| No Status | No CI or deploy check is reporting on this repository |
Status is read from GitHub commit statuses or GitLab pipeline statuses, so it reflects whatever your repository already reports — Vercel, Netlify, GitHub Actions, or your own CI. It polls while a build is in progress and stops once the result is final.
Sitepins doesn’t trigger builds and has no build hooks. It writes a commit; your Git-connected host builds on push exactly as it does for any other commit. If nothing is deployed from the repository, the badge shows No Status — that’s expected, not an error.
Seeing What Changed
The project overview has a Recent File Changes feed showing files created, updated, deleted, renamed, and duplicated, with who did it and when.
If someone else commits to a file you have open, Sitepins tells you right away so you’re not editing a stale version. See Real-Time Collaboration.