What is publishing?

Publishing is the process of moving content changes from one Site to another. When you publish, CloudCannon copies the changes from the Site you have been working on to its Publish Branch: the Site immediately "upstream" that you want your changes to reach.

Moving changes between Sites like this is called a Publishing Workflow, and allows you to draft changes on an independent copy of your Site without affecting the work of other Team Members or the live website your visitors see. To use a Publishing Workflow, a developer needs to set up a Project for your website.

What is a Publish Branch?#

A Publish Branch is the destination Site for your changes. Each Site in your Project has one Publish Branch assigned to it. When you publish, CloudCannon sends your changes from the Site you are working on to that destination Site. Often the Publish Branch is the Site you branched from, allowing you to start with an exact copy of a Site, make intentional changes on that separate copy, and then move them back. For more information, please read our documentation on what branching is.

You can see the name of your Site's Publish Branch on the Publishing page, alongside any changes ready to publish to it. For more information, please read our documentation on the Publishing page.

What happens when you publish#

When you publish a Site, CloudCannon copies your changes to the Site's Publish Branch. There are two methods for publishing changes: Merge Immediately and Pull Request. Merge Immediately allows CloudCannon to move changes from one Site to another without any review process. Pull Request requires the person publishing the changes to submit a request for those changes to move from one Site to another, which requires approval by another Team Member through your Git Provider. Your developer selects which Publishing Method your Project should use. For more information, please read our documentation on what Publishing Methods are.

If multiple Team Members are making changes to the same parts of your website on different branched Sites, publishing your changes may lead to a Publishing Conflict. For more information, please read our documentation on what Publishing Conflicts are and how to resolve them.

Also, if new changes were published to your Publish Branch since you created your Site, CloudCannon will ask you to update your branched Site to match. For more information, please read our documentation on updating from a Publish Branch.

Who can publish?#

Once a developer has set up the Publishing Workflow for your Project, anyone in Default Permission Groups (except Billing) can publish changes from one Site to another via the Publishing page. However, if your Organization uses Custom Permission Groups, you will need permission to publish. For more information, please read our documentation on publishing changes to a Publish Branch.

An example of a Publishing Workflow#

graph BT
  A["Site 3:<br/>Write a new blog"] -->|Publishes to| S["Site 2:<br/>Staging"]
  B["Site 4:<br/>Remove a product page"] -->|Publishes to| S
  C["Site 5:<br/>Update Site navigation"] -->|Publishes to| S
  S -->|Publishes to| P["Site 1:<br/>Production"]

The diagram above shows a common Publishing Workflow with five Sites. "Production" is the live version of your website. "Staging" is a branched copy of "Production", and the three Sites below — "Write a new blog", "Remove a product page", and "Update Site navigation" — are each branched from "Staging".

In this workflow:

• The three draft Sites share a Publish Branch: "Staging". Team Members working on each draft can publish their changes to "Staging" when they are happy with them, without affecting each other's work.
• "Staging" has its own Publish Branch: "Production". Once the combined changes on "Staging" are ready to go live, you can publish them to "Production".

This layered approach is a common publishing pattern. The draft Sites protect your Team Members from each other's in-progress changes, while "Staging" protects your live website from changes you haven't reviewed together yet.