> ## Documentation Index
> Fetch the complete documentation index at: https://docs.poly.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Sub-branches
> A team shares one Branch, splits the work into Sub-branches, and publishes everything together.
Sub-branches are for several people building one update that ships as a package. Any Branch can be split into **Sub-branches**, so a team can divide one piece of work between them and publish it all at once.
If you have not read [Branches](/environments-and-versions/branches), start there. Everything on that page applies here too.
## What a Sub-branch is
A Sub-branch is a copy made from a Branch, rather than from Live. Each person on the team takes their own Sub-branch, works in it, and merges it back into the shared Branch when their piece is done. Once every piece is in, the team tests the whole Branch together and publishes it. Everything lands on Live at once.
Sub-branches follow the same rules with their Branch that Branches follow with Live. They live in [Sandbox](/environments-and-versions/environments), save as they go, and can be tested at any time. A Sub-branch cannot be split into further Sub-branches or moved to Staging. To test its changes in Staging, merge it into its Branch and move the Branch instead.
The navigation bar at the top shows whether you are looking at Live, a Branch or a Sub-branch, and lets you switch between them.
## Working on an update with several people
One Branch for the whole piece of work.
Every Sub-branch comes off that shared Branch.
Each person works in their own Sub-branch. It saves as you go.
Run tests on a Sub-branch to check its changes on their own before merging.
Merge into the shared Branch as each piece is finished.
Test all the changes together.
Move the Branch to [Staging](/environments-and-versions/environments#staging) from its actions menu on the Deployments page, then test it the way a customer would.
Skip this step unless you need to test on a real channel.
Publish the Branch. Everything lands on Live at once.
If the work can ship separately, skip Sub-branches. Each person creates their own Branch and publishes on their own schedule, exactly as described in [Branches](/environments-and-versions/branches#making-a-change).
Branches cannot merge into each other. Each one publishes to Live on its own.
## Handling an out of sync Sub-branch
Out of sync works the same way as it does for [Branches](/environments-and-versions/branches#handling-an-out-of-sync-branch), with one difference. A Branch syncs with Live. A Sub-branch syncs with its parent Branch.
So if a colleague merges their Sub-branch into the shared Branch before you do, your Sub-branch is marked out of sync. Sync to pull their changes into yours, resolve any conflicts, test, then merge. Until you sync, **Merge with parent branch** in the Publish menu is greyed out and labelled **Sync with parent branch first**.
## When someone publishes while Sub-branches are still open
Nothing is lost. Any Sub-branch still open at that point moves to sit directly under Live and becomes a Branch in its own right. Carry on working, then publish it like any other Branch.
## Checking what will change before you publish or merge
On a Branch, open the **Publish** menu and choose **Review changes** to see everything it changes since you created it. On a Sub-branch, choose **Compare changes with parent branch** or **Compare changes with live**. Either way you see the two side by side. Use it to confirm only the change you intended is there.
For how to read a comparison, see [Compare changes](/environments-and-versions/diffs).
## Undoing a publish
If a change goes wrong after publishing, put an earlier version of Live back. See [Roll back a change](/environments-and-versions/introduction#rolling-back-a-change).