# Publishing and your repository

After this page you know exactly what Siteshare does in your repository, and what it never does.

## The draft

What your client changes is saved straight away, as commits on the branch `concept`. Each commit starts with `[skip ci]`, and the client sees their changes in their own preview; nothing is live yet. Cloudflare and Netlify build nothing for these commits. Vercel builds a preview of every branch whatever the message says, so turn that off for `concept` in `vercel.json`:

```json
{ "git": { "deploymentEnabled": { "concept": false } } }
```

Leave `concept` alone. If someone else writes on it, Siteshare tells you.

## Publishing

When your client chooses **Publish**:

1. Siteshare takes in what changed on `main` since the draft began.
2. It checks every changed file against the client's step and what is protected.
3. It builds the site, as your host would.
4. It puts the result on `main` as **one commit**, listing the changes in plain words.

Your host sees `main` change and publishes as it always does. On Cloudflare and Vercel, Siteshare follows what your host reports on that commit and tells the client when the site is live. On other hosts the client hears that the site is updating, and your host takes it live as usual. You get an email with a picture of the page before and after.

**On Netlify**, Netlify tells Siteshare through its deploy notifications. In Siteshare, open the site's **Settings** and find **Netlify**: it has a URL and a JWS secret for this site. In Netlify, open the project and go to **Project configuration › Notifications › Deploy notifications**, and add three with **Add notification › HTTP POST request**: *Deploy started*, *Deploy succeeded* and *Deploy failed*, each with that URL and secret. Only production deploys count; Deploy Previews are left alone. Once Netlify has sent one, **Settings** shows when.

## Your own work

Push to `main` as you always do. Siteshare takes your changes into the client's draft. When your change and the client's cross on the same lines, the client chooses which one stays, and you hear which.

## Restoring

Your client can restore an earlier version from **History**, with **Restore this version**. That is a new commit on `main` with the content of that version: history is never rewritten.

## What Siteshare never does

- Force-push, rebase or rewrite the history of `main`.
- Deploy to your host: publishing is only a commit on `main`.
- Touch anything outside the repositories you gave the app.
- Put a secret, key or preview script in your repository.

## Removing a site

Removing a site from Siteshare takes away what Siteshare put in the repository (the draft branch, and the sign-in page if it added one). Your own work, the history and the live site stay as they are.