Publish a snapshot

Publish Snapshot takes a snapshot of the whole repository's current state and records it as a numbered milestone (Snapshot 7, Snapshot 8, …) that the whole team can see and return to. It is a deliberate, occasional action — not something you do for every edit.

For everyday, file-by-file publishing use right-click → Check In instead. That publishes one file and does not create a snapshot. For publishing all pending changes without creating a milestone, use Check In All at the bottom of the Files tab.

When to publish a snapshot

Cut a snapshot when the project reaches a state worth marking — a design review, a release, a point everyone should be able to come back to. Snapshots are milestones laid on top of the continuous per-file check-in stream, so keep them sparse and meaningful.

What it captures

Publish Snapshot captures everything in its current state, not a selection:

• It commits any modified files that aren't checked in yet.
• It includes any unpublished local versions.
• It pushes anything still unpushed, then tags the current whole-repo state as the snapshot.

There is no per-file checkbox — the snapshot is the entire project as it stands right now.

Blocked on dirty tracked files. Publish Snapshot requires no uncommitted edits among tracked files. If any tracked file has unsaved modifications, GitM blocks the action and prompts you to Check In or Discard first. Untracked files are excluded from the snapshot.

Steps

1. On the Files tab, open ☁ Publish Snapshot — it is the primary bottom button when the repository is clean, or in the ⋯ overflow menu when Check In All is primary.
2. Type a description in the note box — this becomes the snapshot's milestone message.
3. GitM shows a confirmation box summarizing what will be included.
4. Review it, then confirm. Cancel does nothing — no commit, no push, no snapshot.

Expected result

• Any pending changes and local versions are pushed.
• A new numbered snapshot appears on the Snapshots tab, visible to the whole team.
• The snapshot is recorded in .gitm/builds.jsonl, so GitMCloud shows it in the browser too.
• Affected files return to read-only / Not Locked.

Restoring a snapshot later

From the Snapshots tab, Restore this Snapshot resets your whole working project back to that snapshot so you can review it or carry on from it. Restore is non-destructive — it does not rewrite history; you move forward by checking in or publishing again. See Open an earlier version.

Troubleshooting

Symptom	Cause	Fix
"Publish Snapshot" blocked — Check In or Discard first	A tracked file has uncommitted modifications.	Check In or Discard those files, then try again.
"Nothing to publish"	The current state already matches the latest snapshot.	Nothing to do — no changes since the last snapshot.
Confirmation lists more files than expected	Publish Snapshot captures the whole repo, including pending local versions.	Cancel and Check In specific files separately if you only meant those.
Push rejected	The remote moved ahead.	Get Latest, then Publish Snapshot again.

Known limitations

• A snapshot is the whole repository, by design — you cannot publish a snapshot of just some files. Use Check In or Check In All for that.
• Snapshot history is a linear newest-first list, not a branch graph.