Git and Workspace deploys

synsmarts supports two ways to supply the code for a release: Git and Workspace. Both produce a new immutable release and use the same deploy history, validation, build, migration, and traffic-promotion process. They differ in where synsmarts reads the code.

Git deploys read a repository revision

A Git deploy reads a branch, tag, or commit from the GitHub repository connected to the App.

• A branch or tag resolves to its current tip when the deploy starts.
• An exact commit SHA identifies one fixed revision.
• Automatic deploys use Git and run when GitHub reports a push to the configured branch or tag.
• Connecting a repository doesn’t deploy it or enable automatic deploys.

Use Git when the repository is the release record and changes should pass through your normal commit and review process.

Workspace deploys read server-side files

The Workspace is the App’s writable server-side file tree, available through the managed SSH shell and file-transfer tools. After dispatch, the deploy workflow captures the eligible release files when it reaches its source-capture step and builds from that captured context.

There is no branch, tag, or commit to select. Avoid changing the Workspace until the deploy detail reaches Validating, which occurs after source capture. Files copied or edited after source capture aren’t part of that deploy; submit another Workspace deploy to publish the later state.

The captured context isn’t a byte-for-byte copy of the entire Workspace. synsmarts excludes platform-defined runtime, cache, generated, media, and secret paths, plus paths matched by .deployignore. Magento capture preserves a supplied vendor/ tree so a complete production file transfer remains a complete release input; the image builder validates it against composer.lock and the selected PHP runtime before reuse. If validation fails, the build discards that vendor path and reconstructs dependencies with Composer, which requires the applicable private-repository credentials.

Use Workspace for SSH, SFTP, rsync, Deployer, Capistrano, or another workflow that prepares the release files directly on the App.

When a Git repository is connected

A connected repository doesn’t make the Workspace disappear. You can inspect the App through the managed shell and can submit a Workspace deploy from Deploy now or the CLI whenever those files are the intended release.

The two locations aren’t bidirectionally synchronized:

• After a successful Git deploy, synsmarts attempts to refresh the Workspace from the built release so the shell reflects what synsmarts served. Runtime and environment-specific paths, including uploads, media, wp-config.php, and generated configuration containing secrets, are preserved.
• The Workspace refresh doesn’t gate the Git release. If the refresh fails, the Git release remains live and the Workspace can still show older code.
• For non-preserved code paths, the refresh deletes Workspace files that are absent from the built Git release.
• A Workspace deploy doesn’t commit its files to Git, move a branch, or change the connected repository.
• A Workspace deploy doesn’t change the automatic-deploy branch or turn automatic deploys on or off.
• A later Git deploy can replace code changes that exist only in the Workspace.

If a Workspace change must survive future Git deploys, make the equivalent change in the repository and deploy that Git revision. Treat the Workspace as a server-side release source, not as an automatic Git working copy.

Choose the source deliberately

Choose Git when the intended release is already represented by a repository revision. Choose Workspace when the intended release is the file tree currently prepared on the server.

Before deploying, verify the selected source in Deploy now. After the deploy completes, verify the live App against the Git revision or eligible Workspace content you intended to publish.

Before a Workspace deploy on an App with a connected repository, inspect the Workspace itself. Don’t assume it matches the latest Git release.

Deploy history records which source produced each release. Rollback re-serves a previously built immutable release; it doesn’t read or change the Workspace, repository connection, or automatic-deploy setting. After rollback, Workspace can contain newer code than the release currently serving.

For the procedure, see Deploy from Git or Workspace. For command-line examples, see Use the synsmarts CLI.