Skip to main content
Use this guide to hand a Studio change to a professional developer for Git review. The Studio release is the immutable handoff, while Git remains the place where developers review and resolve conflicts.

​
Prerequisites

  • An immutable release created from the completed Studio change.
  • The release version and base Git SHA supplied by the Studio editor.
  • A clean local clone of the Git repository.
  • A dedicated Veryfront API key and project slug in your environment.
  • Permission to push a Git feature branch and open a pull request.
  • .veryfront/ in .gitignore so the local Push receipt cannot enter the pull request.

​
Synchronize main before Studio work

Wait for the serialized CI job to push the latest reviewed Git main source into Veryfront and deploy it to staging. Record that successful job’s Git SHA. Do not start a new Studio change before this Push finishes. Create a non-main Studio branch for the citizen-developer change. Do not edit or publish directly from Studio main. Apply this rule through the team’s source-control policy and CI ownership.

​
Create the Studio handoff

When the Studio change is ready, publish it to a non-production environment, such as staging. Publish creates the immutable release used for the handoff and deploys it only to that selected environment. Open the Releases panel in Studio, open the new release, and copy its Version value. Give the professional developer that version and the Git SHA recorded before Studio work began. You do not need to deploy the unreviewed change to production.

​
Create a Git feature branch

Start from the latest reviewed main branch:
Terminal
git status --short must print no changes. Never pull a Studio release directly into the Git main branch. Record the handoff values and check whether Git advanced after Studio work began:
Terminal
For the safest workflow, stop when these SHAs differ. Push the latest Git main source into Veryfront, recreate the Studio change, and publish a new release. If the professional developer deliberately continues, they own the full Git diff and every conflict resolution.

​
Preview the release

Set the immutable release version and preview the file reconciliation:
Terminal
--prune includes managed local files that exist in Git but not in the Studio release. It does not delete ignored files, unsupported files, or Git metadata. Push and pruning Pulls share the project .vfignore rules. Commit .vfignore as a regular file when the project uses one. Use a release version instead of a mutable Studio branch name. Repeating the Pull for the same release retrieves the same source snapshot. Pull dry-run may run outside a Git worktree and does not write or delete local files. It still validates the remote path set and reports every managed file it would write or delete. Use it before every pruning Pull.

​
Apply the release

Apply the additions, updates, and deletions to the clean feature branch:
Terminal
Pull fetches every managed remote file before it writes locally. A content download failure leaves the feature branch unchanged. A local write or delete failure can leave a partial Git diff. In that case, inspect git status, return the feature branch to a clean state with your normal Git recovery workflow, and then run Pull again. Do not discard unrelated local work. A mutating --prune requires a clean Git worktree. --yes and --force skip only the overwrite confirmation and never bypass the clean-worktree, path, or symlink checks. Pull preserves the release bytes exactly, including line endings and a missing final newline. The release is a full managed-source snapshot, not a patch. Pull overwrites supported text files and prunes supported text files that are absent from the release. It does not perform a three-way merge or auto-merge a stale release with newer Git changes. Ignored, unsupported, and binary files remain outside the reconciliation.

​
Review and test

Inspect every change before committing it:
Terminal
Run the project’s normal format, lint, test, and build commands. Treat the pulled release like any other proposed source change.

​
Commit and open a pull request

Commit the reviewed snapshot and push the feature branch:
Terminal
The pull request targets main and records both the immutable release and its Studio base Git SHA. Reviewers can use those values to trace the handoff and identify a stale snapshot. You can put the same Pull, test, commit, and gh pr create sequence in a repository-owned CI workflow. Keep the Git credential and pull request creation in that workflow. Require the release version and Studio base Git SHA as inputs, write both values into the pull request, and label a mismatch between the base SHA and current main as a stale full snapshot.

​
Resolve conflicts in Git

If main changes before the pull request merges, update the feature branch in Git:
Terminal
Resolve each listed file, run git add --all, commit the merge, and push the feature branch again. Do not resolve Git conflicts by overwriting Git main from Studio. After the pull request merges, the normal CI workflow pushes the reviewed Git main source to Veryfront and creates the staging release and deployment when staging is configured. The approved production workflow uses the same sequence. Wait for that Push before anyone starts another Studio change.

​
Verify it worked

  1. Confirm the pull request diff matches the immutable Studio release.
  2. Confirm required Git reviews and checks pass.
  3. Merge the pull request.
  4. Confirm the serialized CI job pushes and deploys the merged commit.

​
Next