Publish your branch

Your pipeline publishes your project every time your default branch moves. That is enough most days, and it is not enough the day you want your team to try what you are working on right now. Publishing by hand puts the state of your open folder in the company catalogue, without waiting for a merge.

Publish what you have open

Open the workspace menu at the top of the window and choose Publish your local state…. The same entry is in the search palette, under the name it has in the menu.

Ryno asks before it does anything, because the catalogue your team reads is about to change. The box is titled Publish your local state? and says what follows: Everyone in your company will see your requests and shared environments, marked as published by you, until the next merge on the default branch publishes again. Under it, Local environment files stay on your computer.

Cancel leaves the catalogue as it was. Publish sends your state, and the button reads Publishing… while it is on its way. When it lands, Ryno tells you that everyone now sees your version. If your folder has not changed since the last publication, it says so instead of publishing the same thing twice.

What leaves your machine, and what stays

What leaves is what your team versions: your requests, and the environments you share. Nothing else does.

What stays is everything your repository keeps out of Git. Your local environment files never leave your machine, and Ryno names them for you after a publication, under Stayed on your computer:. Flows stay too: a flow runs on a device you have in front of you, so it is not something the catalogue carries.

Publishing needs a Git repository that is already attached to your company, and you signed in. If one of those is missing, Ryno says which one and nothing is sent.

If an administrator removed your project from the company workspace, Ryno tells you instead of publishing: This repository is attached to a removed project., followed by who removed it and when. Choose Attach again to attach your repository to a new project, then publish.

One version at a time

A project has one live version, and publishing replaces it. Yours stands until the next merge on your default branch, when the pipeline publishes again and takes it back. Nothing is lost on either side: a version replaced is a version your team stops reading, not a version that deletes your work.

So publish by hand to have your branch tried, and let the merge put the team back on what everyone agreed on. If you want your version to stay, merge it.

Read where a version comes from

The catalogue tells you where what you are reading came from, at the foot of the list of projects.

Published automatically means the pipeline of the default branch published it: it is what your team agreed on. Published by and a name means somebody published their own folder by hand, as this page describes, and what you read is their branch rather than the default one. Published by an unknown author means the version is there but the service could not say who sent it; read it as published by hand.

The date next to it is the moment the version was published, in the time zone of whoever published it. Together they answer the question worth asking before you test anything: is this the branch your team shares, or somebody’s afternoon?