The question comes up regularly in every game development community: should code and art assets live in the same repository, or separate ones? It seems like a technical infrastructure question. It is actually a question about how your team works and who owns what.
There is no universally correct answer. But there are clear trade-offs, and most teams that try to separate code and art eventually regret it — for reasons that are predictable in hindsight.
The Case for One Repository
Atomic changes
A gameplay feature usually involves both code and assets. A new character needs the C++ or C# class, the Blueprint, the mesh, the material, the animations, and the sound effects. If these live in separate repositories, making them all available together for a build requires coordinating versions across repos. Tagging releases, updating submodule references, ensuring CI uses the right combination — this is coordination overhead that grows with every cross-repo dependency.
In a single repository, a single commit can include everything needed for a feature. The build at any commit SHA has all the code and assets at consistent versions. This is a significant operational simplification.
Simpler onboarding
New team members clone one repository. They have everything they need. They do not need to know that assets live in a different repository, how to configure submodules, or what version of the asset repo the code expects. This seems minor. Over dozens of onboardings, it is not.
Unified history
When a bug appeared in production, the debug starts with "what changed." If code and assets are in the same repository, the answer includes everything that changed — code fixes, asset updates, config tweaks — in one timeline. If they are in separate repositories, you are comparing two independent histories and trying to correlate them by date, which is tedious and error-prone.
Why Teams Split Code and Art
Usually, it is because the combined repository got too large. A team that started with Git finds that after two years, the repository with all assets included weighs 80GB and takes 40 minutes to clone. Rather than fix the underlying problem — version control not handling large binary assets efficiently — they split the repos to make each one smaller.
Splitting solves the symptom. The underlying problem — slow syncs, LFS reliability, checkout bandwidth — remains in the asset repo. And the coordination overhead of keeping two repos in sync replaces the original problem with a new one.
Sometimes teams split because different disciplines want different tools. Artists want something that works in Perforce. Programmers want Git. Splitting the repos allows each group to use their preferred tool. This makes sense if the two groups rarely need to make coordinated changes. If they do, the coordination cost is real.
The Discipline Required for One Repo
A combined repository that works well requires three things that many teams underinvest in:
Proper sparse checkout configuration
A programmer working on AI pathfinding should not need to download 40GB of environment art. Sparse checkout — checking out only the files needed for a given task — is essential at scale. Both Git and Perforce support it. Most teams do not configure it because it requires upfront work. Pay that cost early.
Binary-aware version control
The combined repository fails precisely when the binary assets stress the version control system. Git LFS gets you partway. A system with native delta syncs for binary files, content-addressed deduplication, and lazy fetching gets you the rest of the way. The right answer is not to split the repos — it is to use a version control system that handles the combined load efficiently.
Clear file ownership and locking
One repository means more people touching more things. Clear conventions about who owns which assets, backed by enforced file locking for non-mergeable files, prevents the step-on-each-other problem that makes shared repos painful. The discipline is not technically complex — it is about following consistent habits that the version control system needs to enforce, not just recommend.
The Right Decision
Default to one repository. Split only if there is a specific, concrete reason — usually that the two groups have fundamentally different workflows and never need to make coordinated changes. Even then, evaluate whether fixing the underlying tooling problem is a better investment than managing the coordination overhead of separate repos.
The teams that split code and art because their combined repo was slow made a tooling problem into an organizational problem. The tooling problem was always fixable. The organizational problem of keeping two repos synchronized is ongoing work that does not go away.
Version control should serve your workflow, not shape it. If it is shaping your workflow by forcing you to split what logically belongs together, the version control is the problem — not the decision to keep code and art in one place.