Version Control For TAs

Working With Code And Art Files

Text files can often be merged line by line. Many art formats can't be merged reliably, so the team needs a way to coordinate edits, usually locking or exclusive checkout. Learn those rules alongside the commands. Version control is also something artists may ask you to help with, so knowing how to inspect history and recover a file is useful.

Perforce: The Studio Default

Perforce is common in game production because it handles large binary assets and supports exclusive checkout. A central server holds the shared history; your workspace contains the files you're working on. Check out files, edit them, and submit a reviewed changelist.

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

Your workspace maps server paths to local folders. A changelist groups related changes for submission. Your local revision may differ from the latest server revision, so check and sync before starting work. These distinctions explain many common P4 problems.

Git For Tools And Code

Git is useful for Python tools, shaders, and configuration, even where the art assets live in Perforce. It supports branching and code review well. A typical daily workflow is:

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)

Coordinate binary edits. Use your project's Perforce or Git LFS locking policy before changing files that can't be merged. If someone else has the file, agree a handover.
Keep each submit focused. Group changes that belong to the same task and describe them clearly. That makes review and rollback easier.
Explain the change. A message such as 'Clamp roughness input in the rock material to prevent invalid reflections' is more useful than 'Fixed stuff'. Include the reason where it isn't obvious.
Sync or pull before starting. Resolve the current state before making another set of changes, especially for binary assets.
Exclude disposable caches. DDC and __pycache__ usually don't belong in history. Some generated outputs do need to be tracked for deployment or reproducibility, so follow the project's policy rather than excluding everything a tool creates.

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. Review the detected changes before opening or submitting files, and check for other users’ edits.
"I need yesterday's version of this file"	P4V: right-click -> History -> get revision. Git: `git log -- path` then `git checkout <hash> -- path`. Preserve any current local changes before restoring an earlier revision.
"I committed to the wrong Git branch"	`git checkout right-branch` -> `git cherry-pick <hash>`, then remove it from the wrong one. Preserve the original commit until the change is safely on the intended branch; avoid rewriting shared history without agreement.
"Someone left for vacation with the level locked"	Admins can revert another user's checkout (`p4 revert -C their-workspace` territory). Ask a lead or administrator to coordinate recovery and preserve any unsubmitted work. Before leave, hand over or submit work rather than abandoning it in a locked workspace.
"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. Preserve both versions while deciding what to keep, then agree a locking policy to reduce future conflicts.

A practical example

For example, a pre-submit check can flag binary files edited without the required lock and name the person holding it. The script may be small, but the useful result is preventing an avoidable conflict and making the next step clear.