Git in Unreal teams: binaries, LFS, locking, Perforce

What's different when half the repo is binary assets · 8 min

In one breath

Git was built for text. Unreal projects are mostly binary (.uasset, .umap), which can't be merged and are huge. So teams use Git LFS to keep big files out of normal history, lock assets so two people never edit the same one, and ignore generated folders. Many studios use Perforce instead, which is built around exactly this.

The problem with binary assets

Git LFS (Large File Storage)

LFS stores big files on a separate server and puts a tiny text pointer in git history instead. Clone and checkout download only the versions you actually need. You already use it: WadOfGore's .gitattributes sends 951 files through LFS:

*.uasset  filter=lfs diff=lfs merge=lfs -text
*.umap    filter=lfs diff=lfs merge=lfs -text
*.fbx     filter=lfs diff=lfs merge=lfs -text

Locking: "I'm editing this, hands off"

git lfs lock Content/PlayerCharacter/BP_HeroCharacter.uasset
git lfs locks                    # who has what locked
git lfs unlock Content/PlayerCharacter/BP_HeroCharacter.uasset

With lockable set in .gitattributes, unlocked files are read-only on disk, so you can't edit by accident. Unreal's Revision Control integration (bottom-right of the editor) can lock on checkout, which is the habit that prevents lost Blueprint work.

What not to commit

Generated folders are rebuilt on each machine and must be in .gitignore:

Binaries/   Intermediate/   Saved/   DerivedDataCache/   .vs/   *.sln

Committing them causes constant meaningless conflicts and bloats the repo. (Your .gitignore and the "Ignore generated .slnx solution files" commit are exactly this.)

Line endings: those "LF will be replaced by CRLF" warnings

Windows ends lines with CRLF, macOS and Linux with LF. * text=auto in your .gitattributes makes git store LF in the repo and convert on checkout, so mixed teams don't get "every line changed" diffs. The warning is just git telling you it's doing that. It's harmless.

Perforce: what many studios use instead

GitPerforce (Helix Core)
ModelEveryone has the full history; sync through a remoteOne central server; you sync only what you need
Before editingJust editCheck out the file (can lock it exclusively)
Unit of workCommit, then pushChangelist, then submit (straight to the server)
BranchesCheap labelsStreams: heavier, more managed
Huge binariesNeeds LFSBuilt for it

Epic uses Perforce, and so do most mid-to-large studios. Smaller teams and indies often use git + LFS. The concepts carry over: history, review, small changes, lock binaries. You've used both, which is worth saying in an interview. The full refresher and a model answer are on the Perforce page.

Quiz yourself

Why are .uasset files a problem for git?

Binary: can't be merged, diffs are unreadable, and every version bloats history for everyone.

What does Git LFS actually store in the repo?

A small text pointer. The real file lives on the LFS server and is downloaded only when needed.

Why set up LFS before adding assets?

Files committed before the LFS rule exists are stored in normal git history permanently.

What problem does file locking solve?

Two people editing the same unmergeable asset, where one person's work would be lost.

Name four folders an Unreal project must not commit.

Binaries, Intermediate, Saved, DerivedDataCache (also .vs and generated solution files).

What are the "LF will be replaced by CRLF" warnings?

Git normalising line endings because of text=auto: LF in the repo, your OS's style on disk. Harmless.

Perforce terms for "commit" and "branch"?

Changelist (submitted to the server) and stream.

Why do most studios pick Perforce over git for Unreal projects?

It's built for huge binary assets: exclusive checkout (locking) is native, you can sync only part of a giant depot, and there's no every-version-on-every-machine history like git without LFS.