Publish and get updates
Save in the editor writes the Markdown file to your working copy. That is all it does. No commit, no push, no network. You can save fifty times over an afternoon and the repository will not have moved.
Git happens somewhere else, on purpose: the Sync pill in the header, which opens Sync & collaboration.
The Sync view
Three cards across the top: changes to publish (edits sitting in your working copy), updates waiting (“From your team, based on your last sync”), and current branch. Below them, three actions.
Save a snapshot is the commit. There is one optional field — What did you change?
(optional) — and leaving it empty gives the commit the message Update documents. The button
is greyed out when there is nothing to record. Staging follows the rules in
Connect your Git repository: tracked files that changed,
plus new .md files and _attachments/ content.
Publish pushes the snapshots you have saved to origin. It does not commit for you, so the
order is always Save, then Save a snapshot, then Publish. Success reads Published your changes
for the team; with nothing pending you get Nothing new to publish.
Get updates fetches and then performs a real recursive merge into your branch — the same merge Git would do, not a fast-forward-only shortcut. A clean run says Brought in your team’s latest updates, and an unchanged remote says You already have everyone’s latest updates.
When someone published first
Git refuses a non-fast-forward push, and the editor says so plainly:
Someone published first. Get updates, then publish again.
Do exactly that. If the merge is clean, publish and you are done. If the two of you edited the same lines, the banner changes to Some changes clash with yours. Let’s merge them together and sends you to the three-pane merge described in Resolve conflicts.
A rejected sign-in has its own message — Could not sign in to the remote. Check your credentials under Settings. — with a link straight to the credentials fields.
Nothing syncs in the background
There is no timer that fetches for you and no daemon that pushes on your behalf. Every commit, every pull, and every push is a button you pressed. The Sync pill does poll, but only your local repository state, which is why updates waiting is honest about being measured from your last sync rather than from the remote right now.
The upshot is that your working copy never changes while you are typing in it, and your team never sees a half-finished page because an editor decided to be helpful.
How the server picks it up
The DocuCommit server (read-only web app) pulls the repository on a schedule — every 5 minutes
by default, set with DOCUCOMMIT_SYNC_INTERVAL — and can also be nudged immediately by a
webhook from your CI, so a published change appears within minutes without anyone touching the
server. See Run the server with Docker.