Every game studio eventually hits the same wall. Someone pushes a 2GB texture file to Git. The repo slows to a crawl. The lead programmer spends two hours explaining to the art team why they cannot just commit everything to main. A senior artist loses a week of work because a merge stomped their changes. Sound familiar?
This is not a workflow problem. It is a tool problem. Git was designed by Linus Torvalds in 2005 to manage the Linux kernel — millions of lines of C code, no binary assets, a team of experienced engineers who understood version control deeply. It was not designed for a 60-person studio trying to ship a 100GB open-world title with contributions from programmers, technical artists, level designers, and audio engineers who just want to get their work into the build.
What Makes Game Development Different
The fundamental mismatch between standard source control and game development comes down to a few specific problems that compound each other.
Binary assets dominate the repo
A typical game project might have 50,000 lines of code and 40GB of assets. The ratio flips from what Git expects. A texture file, a WAV, a compiled shader — none of these are human-readable, none of them can be diff-ed meaningfully, and they can be huge. Git is built around text diffing. Storing binaries in it works poorly from the start and gets worse as the project grows.
Git LFS was designed to address this. It moves large files out of the main object store and into a separate server, storing a pointer in Git instead. This helps — but it introduces a new failure mode. LFS servers can get out of sync. Cloning becomes slow in unpredictable ways. The pointers can break on certain operations. And it adds operational complexity that game teams should not need to manage.
Non-mergeable files are common
Two programmers editing the same C++ file can usually resolve their conflict in minutes. Two level designers editing the same Unity scene file? That is a coin flip. Unity scenes are YAML, which is technically text, but the structure is generated by the engine and does not merge cleanly in practice. Unreal's Blueprint files and uasset format are binary — they cannot be merged at all by standard tools.
The standard answer is file locking: one person holds the lock, nobody else can edit. Perforce has built-in pessimistic locking that many studios rely on. Git has no native locking. Teams bolt on external solutions, enforce conventions manually, or just accept that someone will occasionally lose work.
Mixed teams have different workflows
A programmer is comfortable branching, committing frequently, and resolving conflicts at the terminal. A 3D artist or audio designer probably is not. They may work in tools — Maya, Substance, Fmod — that do not integrate naturally with command-line Git. They want to save their work and see it in the build without thinking about staging areas, commit messages, or merge strategies.
When version control is designed for one discipline and retrofitted for others, friction shows up everywhere. Artists stop committing. Work goes unsaved. Merge days become a team event that blocks everyone for hours.
Why Perforce Is Not the Answer Either
Perforce Helix Core is the other option most studios consider. It handles binary assets natively, has real file locking, and supports large repos. Many AAA studios use it. But it comes with its own costs.
Perforce requires significant infrastructure to run — dedicated servers, ongoing administration, expert configuration. The branching model is rigid compared to Git. Offline work is limited. The licensing costs are real. For studios below a certain size, the operational overhead of Perforce is the problem, not the solution.
The studio tooling market split: smaller studios reach for Git and fight it, larger studios pay for Perforce and live with its constraints. Neither group is well-served.
What a Purpose-Built Tool Looks Like
The requirements are not that complicated once you state them plainly. A version control system for game studios needs to:
- Handle large binary files without degrading performance
- Support pessimistic file locking for non-mergeable assets
- Work from inside the engine editor, not just a terminal
- Branch and merge without requiring everyone on the team to understand the internals
- Import history from Git or Perforce so studios can migrate without starting over
- Run as a managed service so studios do not need to host and maintain their own infrastructure
None of these are exotic requirements. They are what studios need, and they have not been met by either of the dominant options.
That is the gap Diversion exists to fill. Not a wrapper around Git, not a fork of Perforce — a ground-up design that treats game assets as first-class citizens from day one.
The studios in our early access program are not early adopters looking for novelty. They are teams that have tried both options and found them wanting. That frustration is real, the use case is clear, and the tooling has been missing. That is what we are here to fix.