Game asset versioning best practices

Source control on a game project has one job: never lose work, ever. Everything else — speed, storage costs, workflow elegance — comes second. When a decision trades reliability for convenience, it's almost always the wrong trade.

That sounds obvious, but it's the thing teams forget when they skip locking, stop versioning, or trust that Google Drive will "probably be fine" for the texture folder.

Commit source artifacts. Exclude derivatives.

Source artifacts are the files a human made or that are non-trivial to regenerate: .psd, .blend, .fbx, .wav, .uasset, .unity scenes, .godot scenes, engine source code, config files.

Derivatives are files the engine or build system regenerates from source: Library/, Intermediate/, DerivedDataCache/, compiled shaders, build output, .godot/ cache. These don't belong in source control — they bloat storage and create spurious changes.

Asset naming gets a disproportionate amount of hand-wringing and not enough discipline. A few rules that pay off:

• Stable names over descriptive names. Character_Boss_01 survives rework; FinalBoss_AngryDragon_v2_REAL_FINAL doesn't.
• Prefix by type. T_ for textures, SM_ for static meshes, M_ for materials. Makes search and bulk operations tractable.
• No versions in filenames. Version control versions files. Youshould not. If you're tempted to create character_v2.fbx, commit character.fbx and let history track versions.
• Case consistency. Windows is case-insensitive, Linux (your CI) is not. Pick a case convention and stick to it.

Binary files can't merge. Textures, FBX models, Unreal blueprints, Unity prefabs (when binary), audio sessions — if two people edit concurrently, someone loses work.

The rule: lock before you edit binary files. Always.Even "just a quick tweak." Even when you're 99% sure no one else is in there.

Good locking habits:

• Short, informative lock messages."wip balance pass L3, ETA 2h" is useful. "editing" is not.
• Release locks at end of day, even if you're mid-work. Commit what you have, release, re-lock tomorrow. Dangling locks across time zones block teammates.
• Use force-release sparingly. Admins can force-release, but doing it without asking the lock holder is a great way to lose trust and occasionally their work.

Teams that lose work usually lose it at commit time — sloppy commits, unreviewed changes, broken scenes pushed for the whole team to sync.

Habits that prevent trouble:

• Commit working state, not "wip." If your scene doesn't open, don't commit it. The one exception: end-of-day backup commits to your own branch or stash — mark them clearly.
• One logical change per commit. Easier to understand in history, easier to roll back if it breaks something.
• Readable messages."Added boss intro cutscene, wired up trigger" beats "stuff."
• Review the file list before committing. Accidentally adding Library/ to a Unity project or Saved/ to an Unreal one is the #1 way to balloon storage.

Source control is your primary backup, but it's not your only backup. Good practice:

• Commit often. A commit-per-day minimum for every team member. A commit-per-session is better.
• Tag releases and milestones. When you ship a playtest build or hit a milestone, create a named checkpoint. Makes rollback trivial.
• Off-platform snapshots for critical milestones. For major milestones, download a local copy. One backup is no backup.

A new team member's first day decides whether they develop good source control habits or bad ones. Invest:

1. Walk them through the first commit — not just "here's the app, figure it out."
2. Show them locking. Have them lock a file, edit it, commit, and see the lock release.
3. Demonstrate rollback. Seeing "we can always get the old version back" changes how people work.
4. Point them at the team's conventions — naming, folder structure, commit style.

"We'll add source control later." Adding source control after months of parallel work is painful. Start on day one, even if you're solo.

Saving everything in Dropbox. Dropbox has no locking, no meaningful version history, and creates conflict copies that ruin binary files. It is not source control.

"Just one more uncommitted change." Uncommitted work is unbacked-up work. Commit, or prepare to lose it.

Committing huge regenerable folders. Library/, Saved/, and Intermediate/ aren't project state; they're cache. Exclude them.

Mixing personal config with project config. UserSettings/ (Unity), per-user workspace files, .vs/, and .idea/ are personal — exclude them from commits.