Skip to content

Review and publishing

Studio’s review workflow is built on GitHub pull requests. Open a pull request for the changes on your branch, review them with your team, merge to publish, and watch the deployment — all without leaving Studio.

Pull requests always target the production branch. See Branches and environments for the full branch model.

When the active branch has unpublished changes, the content browser shows a banner: N unpublished changes on branch-name, with a Review button. Clicking Review:

  • Opens the existing open pull request for the branch if there is one, or
  • Creates a new pull request whose base is your production branch, then takes you to the PR detail view.

You can also open the review queue at any time from the Studio nav rail.

The Reviews screen lists every open pull request for the project. Each entry shows the PR number, title, author, the source branch (head), the target branch (base), the number of changed files, and how long ago it was opened.

From the queue you can:

  • Click a row — opens the pull request’s detail view.
  • Approve & merge — merges the pull request without leaving the queue (after a confirmation dialog).
  • Refresh — reloads the queue.

After a merge, the queue keeps showing the deployment-status card described under Watching the deployment below.

Open a pull request from the queue or from the Review button. The detail view has three parts:

The toolbar shows the PR number, title, and an Open or Closed status badge. From the toolbar you can:

  • GitHub — open the PR on GitHub in a new tab.
  • Close — close the PR without merging (open PRs only, with confirmation).
  • Merge — merge the PR (open PRs only, with confirmation).

If GitHub blocks the merge under a branch-protection rule, Studio shows a “Merge blocked by branch protection” message in place of a generic error.

The main column shows the source and target branch, the file count, the author, and the time the PR was opened. Below this is a list of changed files. Click a file to expand it and see its diff.

For most files Studio renders a unified code diff. For content files (anything under src/content/ with a .md, .mdx, .yaml, .yml, or .json extension) you can toggle between two views:

  • Content view — shows frontmatter changes and a line-level body diff.
  • Code view — shows the raw unified diff.

Inside the diff, hover any line and click the + icon to add an inline comment. The comment box appears under the line. Press Cmd/Ctrl+Enter or click Comment to post it, or Cancel to dismiss.

The right column shows the top-level comment thread. Comments from reviewers using GitHub appear here alongside comments posted from Studio. Inline comments are rendered next to the line they refer to in the diff.

To add a top-level comment, type into the box at the bottom of the comments column and click Comment (or press Cmd/Ctrl+Enter).

After you click Merge, the merged pull request triggers your project’s deployment workflow. Studio polls the deployment and shows a status card with one of the following states:

State What it means
Waiting The workflow run has not started yet.
Queued Queued in GitHub Actions.
In progress Building and deploying.
Completed (success) Deployed successfully.
Completed (failure) The workflow run finished with a failure.

A View build link opens the workflow run on GitHub, and a Dismiss button (the X icon) hides the card.

After a successful merge, the detail view offers to delete the branch and its preview environment in one step. Click Delete branch to remove both. Studio deletes the preview environment first, then the Git branch, so a partial failure does not leave you with an orphaned environment.

If you prefer to clean up later, manage branches manually from Branches and environments.

  • Deployments — view all workflow runs, expand jobs, and read step-level logs
  • Permissions — control who can review and merge content in your Studio project