# Publish and get updates

> How a saved page becomes a commit and reaches your team — Save, Save a snapshot, Publish, and Get updates in the editor.

**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

![The Sync & collaboration view: changes to publish, updates waiting, and the current branch, above Save a snapshot, Get updates, and Publish](/images/docs/sync-and-collaboration.png)

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](/docs/getting-started/connect-git/): 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](/docs/collaboration/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](/docs/self-hosting/docker/).