Version Control For TAs

Why Artists Fear It, And Why Studios Don't Care

Version control was designed by programmers for text, where two people's changes can be merged line by line. Art files are binary: a .blend, a .psd, a .uasset cannot be merged, only overwritten. So artists' first experience is usually a cryptic error eating an afternoon's work, and the fear is rational. The fix is not avoiding version control. It is learning the binary-file rules, mostly lock before you edit, that programmers never had to learn. Studios require it because production without it is one disk failure away from ruin. As a TA, you are not just a user either. You will be the person artists ask when it breaks.

Perforce: The Studio Default

Most AAA and mid-size studios run Perforce (P4) because it handles enormous binary files well and supports exclusive checkout - locking a file so two artists can't silently overwrite each other. The mental model in one line: a central server owns the truth; you check files out, edit, and submit back.

The daily loop, in the five commands (or their P4V button equivalents) you'll actually use:

P4 - the daily survival kit

# morning: get everyone else's work
p4 sync

# before editing anything (this is the lock - the whole point for binary files)
p4 edit Assets/Props/SM_Crate_01.fbx

# see what you have open
p4 opened

# submit, with a message a human can act on
p4 submit -d "Crate LODs: added LOD1/2, fixes streaming hitch in dock level"

# made a mess? un-checkout, restore server truth
p4 revert Assets/Props/SM_Crate_01.fbx

Three P4 concepts that unconfuse everything: your workspace maps server paths to a folder on your disk - files edited outside that mapping are invisible to P4 (the #1 "where did my work go"); a changelist is a named basket of files submitted together - one task, one changelist; and "latest revision" is not "your revision" - sync before you start or enjoy building on Tuesday's assets.

Git: The Other Half Of Your Life

Your Python tools, shaders, and configs belong in Git even when the art lives in P4 - it's better at code, branches, and code review, and it's what the engineers use. The TA daily loop:

Git - the daily survival kit

git pull # get latest
git checkout -b fix-export-axis # branch per task
git add tools/exporter.py
git commit -m "Exporter: apply -90X on FBX export so UE gets Z-up right"
git push -u origin fix-export-axis # then open a PR/MR

If a project keeps art in Git, it needs Git LFS - large binaries stored out-of-band, pointers in the repo. Two files make an art-friendly Git repo, and as the TA you'll be the one who writes them:

.gitattributes - route binaries through LFS, lock 'em

*.psd filter=lfs diff=lfs merge=lfs -text lockable
*.blend filter=lfs diff=lfs merge=lfs -text lockable
*.fbx filter=lfs diff=lfs merge=lfs -text lockable
*.png filter=lfs diff=lfs merge=lfs -text
*.uasset filter=lfs diff=lfs merge=lfs -text lockable
*.umap filter=lfs diff=lfs merge=lfs -text lockable

.gitignore - the DCC droppings that never belong in a repo

__pycache__/
*.blend1
*.ma.swatches
/Intermediate/
/Saved/
/DerivedDataCache/
.vs/
*.tmp

The Golden Rules (Both Systems)

Binary files: lock before editing. P4 exclusive checkout or LFS locks. Two people editing one .uasset means someone's day evaporates - the lock turns a disaster into a Slack message ("hey, you done with the crate?").
Submit in task-sized atoms. One fix, one submit, one description. A 47-file "misc updates" submit is unrevertable and unreviewable - it's where history goes to die.
Write messages for the 2 a.m. reader. "Fixed stuff" helps nobody; "Rock master material: clamped roughness input, NaN was blowing out SSR" lets someone triage without opening the file. That someone is usually future-you.
Sync/pull before you start, not after you finish. Merging your afternoon into someone else's morning is misery in text and impossible in binary.
Never version-control generated files (DDC, __pycache__, bakes that rebuild). They bloat history and cause phantom conflicts. If a machine made it, a machine can remake it.

Fixing The Classic Disasters

Disaster	The fix
"I edited without checking out and now P4 won't take it"	`p4 reconcile` - scans your workspace and opens the changed files properly. The undo-hostility of this workflow is why the checkout habit matters.
"I need yesterday's version of this file"	P4V: right-click -> History -> get revision. Git: `git log -- path` then `git checkout <hash> -- path`. This one operation justifies the entire system.
"I committed to the wrong Git branch"	`git checkout right-branch` -> `git cherry-pick <hash>`, then remove it from the wrong one. Nothing committed is ever really lost.
"Someone left for vacation with the level locked"	Admins can revert another user's checkout (`p4 revert -C their-workspace` territory). Ask a lead - don't wait five days, and don't be the person this table entry is about: revert your checkouts before vacation.
"Git says merge conflict on a .png"	Don't "resolve" - pick a side: `git checkout --ours` (yours) / `--theirs`, then make the other change again by hand. And add the lockable flag so it can't recur.

From the trenches

The most beloved tool I ever shipped took forty minutes to write: a pre-submit check that refused any changelist touching a .uasset without a checkout lock, with an error message that named the other person who had it open. Merge disasters went from monthly to never. Nobody remembers my shaders. Everybody remembers "the thing that tells you who has the file."