Skip to content

Concepts

Background reading that explains how GitM thinks. These pages are explanatory, not step-by-step — for tasks, see the Designer guide.

  • Check out and check in — the lock-based edit loop and why files are read-only.
  • Placeholders — why some files are dimmed with a ·placeholder· badge and only download on demand.
  • Versions and snapshots — the two timelines: everyday per-file Check In (cloud versions, no snapshot) vs. Publish Snapshot (whole-repo milestones).
  • How GitM uses GitHub — the repository as a PDM store, Git LFS, .gitattributes, and the .gitm/ metadata files (including what GitMCloud reads).

The one-paragraph version

Your team's files live in a GitHub repository. GitM sorts every file into a bucket — source (native SolidWorks), library (read-only reference parts), derived (neutral/2D exports), and documents/images — and the bucket decides how it's stored and whether it can be locked. Source files (and library parts) make up the working set shown by default; derived files and documents are outputs revealed by the Doc toggle in the Files toolbar. Every SolidWorks file is stored in Git LFS and marked lockable, which makes it read-only on disk until you check it out (acquire a lock). You edit, then check in that one file — GitM saves, publishes to GitHub, and releases the lock in one action. When you want to mark a milestone you Publish Snapshot, which captures the whole repository's state; snapshots appear on the Snapshots tab and can be restored. To save space, files can stay as lightweight placeholders until you make them available on this PC. A companion service, GitMCloud, reads the repository to show BOMs and to manage part numbers, and gates who is allowed to onboard.

Some features described here depend on GitMCloud — see GitMCloud docs.