Version control for 3D is harder than for code, because the files are binary, large, and cannot be merged.
Why the usual tools struggle
- No diffs. Two versions of a mesh differ in ways a text diff cannot express.
- No merging. Two people editing one model produces two models, not a merge.
- Size. A repository's history grows with every version of every large binary.
Locking instead of merging
The workable model is exclusive checkout: an artist locks a file, edits it, releases it. Nobody else can edit it meanwhile. That prevents the conflict rather than resolving it, which is the only option for unmergeable files.
Large file handling
Systems designed for binary assets, or extensions to text-oriented systems that store large files separately, keep repository size manageable. Without one, cloning a project becomes impractical within months.
What to version
- Source files — the authoring documents.
- Exported assets consumed by the engine.
- Textures, source and exported.
What not to
- Generated intermediates that can be rebuilt
- Engine caches and derived data
- Personal settings
A clear ignore list matters more here than in code, because accidentally committing a cache directory can add gigabytes.
Practical habits
- Commit often, in meaningful units. "Finished the crate" rather than a week of work.
- Never leave files locked longer than needed.
- Write real messages. With no diff to read, the message is the only record of what changed.
- Tag milestones, so a known-good state is findable.
Generated assets
Worth versioning the inputs — the prompt, the reference images, the settings — alongside the output. A generated mesh with no record of how it was made cannot be regenerated or varied, which turns a repeatable process into a one-off artefact.