The problem is coordination, not tooling
Almost every Unreal team that loses a day loses it the same way. Two people opened the same asset. Neither knew. One saved after the other, and an afternoon of work stopped existing.
It is tempting to treat that as a version control problem, and partly it is. But the tool can only tell you a file is taken. Whether anyone asks before they open it is a working agreement, and the teams that stop losing days are the ones that make that agreement explicit rather than assuming everyone will be careful.
Unreal Engine 5 genuinely improved the technical half. World Partition and One File Per Actor removed the level-file bottleneck that used to force people to take turns. What they did not do is make Blueprints, materials, or individual actors mergeable, so the coordination half is unchanged.
What the team shares, and what it doesn't
Getting this wrong is the most common onboarding failure, because it produces problems that look like engine bugs.
Everyone shares: the .uproject, Content/ (including __ExternalActors__ and __ExternalObjects__ if you use World Partition), Config/, Source/, and Plugins/.
Nobody shares:
Saved/ ← per-machine state, autosaves, logs
Intermediate/ ← build intermediates
DerivedDataCache/ ← regenerated; will destroy your storage budget
Binaries/ ← compiled output
Build/ ← platform build artifacts
.vs/ *.VC.db ← IDE stateEvery one of those is regenerated from what you do share. Committing them causes spurious conflicts on files nobody edited, which is exactly the kind of noise that trains a team to ignore their version control.
.gitignore needs to cover before the first commit, not after.Dividing the work so people don't collide
The goal is that on any given day, two people rarely want the same file. A few patterns get you most of the way there.
Divide by feature, not by file type. Group everything for one system, its Blueprints, materials, meshes, and data, into one folder. It means one person can own a feature outright, and it makes the ownership question answerable by looking at a path.
Use data layers for shared space. In a World Partition world, give each discipline its own data layer over the same physical area: environment art, lighting, gameplay scripting. People load only their layer plus context, which keeps editor load times sane and makes ownership obvious.
Split assets that everyone touches. A character Blueprint five people edit every sprint is a bottleneck wearing a costume. Break it into components. The refactor costs a day and pays it back within a month.
Sequence tasks that share an asset. If two sprint items both need the player controller, decide in planning who goes first. Discovering it mid-week means one of them wasted the week.
The locking habit
This is the one rule that matters more than everything else on this page, and it fits in a sentence: lock before you open, not after you start editing.
Locking after you have already made changes defeats the purpose, because the collision has already happened, you just have not found out yet. The lock is a question you ask before you commit time, not a flag you raise once you are invested.
The habits that make it stick:
- Write useful lock messages."boss arena lighting pass, ~3h" lets a teammate plan. "editing" tells them to go and ask you.
- Release at end of day. Commit what you have, release, re-lock tomorrow. An overnight lock blocks the half of your team in another timezone.
- Force-release only after asking. Admins can break a lock. Doing it without a message is how you lose both the work and the trust.
- Lock the level file for structural changes. Partition settings and data layer definitions live in the
.umap, which is still shared and still binary.
A commit rhythm that protects people
Game assets are binary, so a commit is a full snapshot rather than a diff. That has a consequence people underestimate: an uncommitted afternoon is genuinely unrecoverable. There is no partial state to salvage from a dead drive.
Commit at natural milestones during the day, and always before you stop. Not because a process document says so, but because the alternative is that your safety net has a hole the size of however long you have been working.
Write messages in the language of the game rather than the file system. Nobody can read the diff of a texture to reconstruct what you meant, so the message is the only record that survives. "Warmer palette on the market stalls per art review" is useful in six months. "Updated assets" is not.
Onboarding someone in an afternoon
The measure of whether your setup is actually working is how long it takes a new person to make their first meaningful commit. If that is a week, something in the list above is missing.
The path should be roughly this:
- Install the desktop app, paste the project key, pick a folder.
- Sync. This is the long part, and it is bounded by your project size and their connection rather than by anything they have to understand.
- Open the project. It works, because the exclusions were right and nobody committed their
Saved/folder. - Read one page of team conventions: what to lock, how folders are divided, which data layer is theirs.
- Lock something small. Change it. Commit.
No server credentials, no client spec, no LFS installation, no explanation of why some files are 130-byte text stubs. The shortest onboarding is the one with the fewest concepts in it.
Frequently asked
How do multiple people work on the same Unreal Engine 5 level?
With World Partition and One File Per Actor, each actor saves into its own file, so people editing different actors in the same level never touch the same file and never conflict. What still needs coordination is the level file itself (grid and data layer settings) and any single actor two people both want. Data layers are the usual way to divide a shared space by discipline.
What should be in .gitignore for an Unreal Engine 5 project?
Saved/, Intermediate/, DerivedDataCache/, Binaries/, Build/, .vs/, and *.VC.db. All are regenerated from what you do commit, and versioning them causes spurious conflicts on files nobody edited. Do commit the .uproject, Content/ (including __ExternalActors__ and __ExternalObjects__), Config/, Source/, and Plugins/. In USourceControl these exclusions are the default.
How do I stop my team overwriting each other's work?
Exclusive file locking, applied before opening rather than after editing. Binary assets can't be merged, so the only reliable prevention is that the second person is told the file is taken before they invest time. Pair it with useful lock messages and releasing at end of day, and the problem largely disappears.
Can we use branches in Unreal Engine 5?
Yes, and sparingly is the right dose. USourceControl has branches: fork from main, commit on the branch, merge back, resolving any file that both sides touched. But branching is only cheap when merging is automatic, and merging binary assets never is. Short-lived branches for code, engine upgrades, or a release freeze work well. Long-lived feature branches over shared Content end in a choice about whose week to discard. Most teams run one line with locking, and reach for a branch when they need to isolate something risky.
How long should onboarding a new team member take?
An afternoon, most of which is the initial sync. If it takes a week, the cost is usually concepts rather than bytes: server credentials, client specs, LFS setup, or a wrong exclusion list that makes the project fail to open. Removing concepts is what shortens it.
Do we need a producer to manage this?
No, but someone has to own the conventions. What to lock, how folders divide, which data layer belongs to whom. That can live in a one-page document. What doesn't work is assuming everyone will independently arrive at the same answers.