Documentation / Projects and Collaboration

Save and Sync

Understand what Save, Commit, Push and Pull change in a Workspaces project.

Save your intended work, record it locally, then publish it to the intended branch. Pull retrieves changes published on that branch.

Save, Commit, Push and Pull

  • Save writes editor changes to local files. It does not publish.
  • Commit creates a local Workspaces checkpoint. Other devices and teammates cannot retrieve that commit from the cloud yet.
  • Push publishes reviewed local work to the checked-out cloud branch.
  • Pull brings that branch's cloud changes into your local working copy.

An AI-edit snapshot or conversation version is not a Workspaces Push. See Local history and rollback.

Publish changes

  1. Open the intended Workspaces project and check its checked-out branch.
  2. Save the editor changes you want included. If disk and editor disagree, reconcile them before saving.
  3. Review Changes, including native design files, drawings, dependencies and the shared notebook. Use Ignore rules to inspect .traceignore.
  4. Choose Commit, enter a meaningful summary, and confirm the native review.
  5. Choose Push and review the work and branch being published.
  6. Read the completed result. Confirm that the cloud branch contains the intended revision; a local commit alone is not publication.

Push can include a local commit step when the supported review offers it. Do not assume it only publishes existing commits: inspect the saved files and local commits the review actually includes.

Standalone Commit and Push operate on the source branch. If choosing either inside a pending branch-switch review, follow its displayed continuation behavior, which differs by build. A completed Commit or Push alone does not prove a branch switch completed.

Pull changes

  1. Check the open project and branch.
  2. Save intended editor work and inspect local file changes and unpushed commits.
  3. Choose Pull and review the update.
  4. If changes overlap, use the conflict review before applying.
  5. After completion, inspect the updated files in the editor and run the relevant electrical or layout checks.

An already-current Pull is a successful no-op; it does not need to reload the editor. Other Pulls need actual local application and the appropriate editor reload before the GUI workflow is complete.

Read-only access may permit Pull where the current project allows it. It does not grant Commit, Push or local authoring permission.

Review the right state

Unsaved editor buffers, saved disk changes and unpushed commits are separate. An empty Changes list can still accompany unpushed commits. An unavailable or stale status is not evidence that there is nothing to preserve.

.traceignore controls eligible project content, not your cloud permissions. Do not ignore tracked .xo files to conceal authored changes or bypass a switch. Personal rules and operational metadata are not the shared design notebook; see Project rules.

In compatible builds, firmware handoff notes under .trace/firmware/ can be shared project content. Review their inclusion and cited documents before Commit and Push. The AI Workflows preference remains local; creating or exporting notes does not publish them automatically.

If a command fails

A failed Push may preserve a newly created local commit without publishing it. Local commit preserved means exactly that, not cloud success. Keep the work and use the original command's recovery controls.

If delivery is unknown, do not issue another Push/Pull or invent a new request. Check the original operation first. Only after its outcome is settled should you authorize a new reviewed action.