From Workspace to pull request

Everything you do in a Workspace is a change to your real code, and Ship is how it reaches GitHub as a pull request your team can review, through the same review, CI, and merge process as any other change. Where that work lives depends on how the Workspace started: as new work in Soffi, or from a pull request someone already opened.

Two ways a Workspace starts

A Workspace started in a Project is always cut from the Project's setup, never from someone's open pull request, so the Project's other pull requests don't leak into your work. A pull request's Workspace covers just that pull request and its one repository. There is one per pull request, so everyone who opens it from GitHub lands in the same place.

A pull request that came out of a Workspace links back to it with Edit in Soffi on GitHub, so anyone following it from the pull request opens the Workspace that made it, not a second copy.

What Ship does

When the work is ready, choose Ship in the Workspace. Soffi opens Review and ship, which lists what's about to go out, with one section for each repository the Workspace changed. Each section says what shipping does there: Create PR for that repository the first time, or Push changes to the pull request that's already open. Under it you see the design token changes and the files that changed, and a Past changes section shows what those pull requests already carry.

Choose Ship to send all of it. Soffi opens or updates one pull request per repository, and each one that lands appears with a View in GitHub link. If one repository fails, you can retry just that one.

For a new pull request, Soffi writes the title and description from the work itself while the review is open, so the pull request explains what changed without anyone writing it up by hand.

Shipping again

A Workspace keeps its pull requests. When you make more changes after review feedback, open the Ship menu and choose Push changes, and Soffi pushes the new work to the same pull requests instead of opening new ones. The same menu lists the Workspace's pull requests and their state. The review conversation on GitHub stays in one place.

Who opens the pull request

Each section of Review and ship notes who the pull request opens as.

• You, when you've connected your GitHub account to Soffi and that account has write access to the repository. The pull request is yours, like any other you open.
• Soffi, otherwise: when you haven't connected GitHub, your GitHub session has expired, or your account can't write to that repository. Soffi then opens the pull request itself, and the note says why.

Ship works either way, so connecting GitHub is optional. To open pull requests under your own name, connect GitHub from the card on the Workspaces page or from the sign-in chip in Review and ship. A pull request that's already open keeps whoever opened it, even when someone else pushes to it later.

Shipping needs the Editor role or above. See Roles and permissions.

Before and after images

A pull request you Ship carries before and after screenshots of the screens you changed in its description, with nothing to turn on. For pull requests opened outside Soffi, Admins can turn on automatic comparisons in the Project's settings. Both are covered in PR visuals.

After you ship

From here it's an ordinary pull request. Your engineers review it in GitHub, your CI runs on it, and your team merges it when it's ready. Soffi never merges for you and never deploys to production. Once every pull request a Workspace opened has merged, the Workspace's work is done and Soffi archives it. A pull request's Workspace is archived when that pull request merges or closes.

The sign-in change Soffi makes for previews is never part of what Ship pushes. See Sign-in in previews.