Publishing
When you publish, your changes are merged onto Live. Merging means your changes are added on top of what is already there, rather than replacing it. That matters when more than one person is working on a project. If a colleague publishes their Branch while you are still working on yours, your change is added on top of theirs. If you both changed the same thing, you are asked which version to keep before anything goes live. Nothing is lost silently.Rolling back a change
Every publish is saved as a version in Live’s history. If a change goes wrong, you can roll back to an earlier version in one step.
Live history on the Deployments page, with every published version in order
1
Open Live history on the Deployments page
Every publish is listed there as a version.
2
Choose an earlier version and roll back
Live returns to that version in one step. Nothing else changes.
While an experiment is running, rolling back waits until you end it.
Two ways to work
Every project can have as many Branches as you need, and any Branch can be split into Sub-branches. You decide which to use for each piece of work, depending on whether the change ships on its own or as part of a larger update.Terminology
Related pages
Branches
Everyone works in their own Branch and publishes when ready.
Sub-branches
A team shares one Branch and ships an update together.
Environments
What Sandbox, Staging and Live are, in plain English.
Compare changes
See exactly what will change before you publish.
Everyday practice
Hotfixes, seasonal updates and best practice, in the Academy.
Environments and testing FAQ
Common questions about Sandbox, Staging and Live.
Experiments
Run a Branch against Live on real calls and keep the winner.

