Version Control When the Repository Is Mostly Binary Assets

A modern game repository is not a codebase. It is a massive, mutable database of uncompressed audio, raw textures, and proprietary binary blobs. Text files make up a fraction of the storage footprint.

The decision of which version control system to use presents as a technical evaluation, but it is actually a negotiation between programmers who expect distributed branching and artists who require exclusive file locks. The system you choose dictates which group has to compromise their daily workflow.

The Math of Binaries

Git’s delta compression is a magic trick that only works on text. On binaries, it is just overhead. A 500MB texture with 40 revisions is roughly 20GB in a Git packfile. Multiply that by every asset in the project.

At ten gigabytes, any version control system works. At five hundred gigabytes, the tools built for text begin to crack. At five terabytes, moving assets between the server and the build farm becomes a dedicated infrastructure discipline. The repository is not the game, but its growth rate is a leading indicator of your infrastructure debt.

Git and Large File Storage

Git Large File Storage (LFS) replaces binaries with text pointers. The local repository stores tiny text files containing a hash. A hook reads the hash and downloads the binary blob from a separate server. This keeps the repository clone small, but it removes the decentralized backup advantage of native Git. A pointer file is not the asset; the build needs both.

Git with LFS is a reasonable fit when the team is mostly engineers, asset collisions are infrequent, and the repository is under a few hundred gigabytes. It begins to fail when the team scales and the assets become highly contested.

Git LFS file locking is an overlay, not a foundational mechanic. It is advisory by default. If an artist checks out a character model and goes to lunch, a second artist can ignore the advisory lock, edit the file, and submit. The first artist’s work is overwritten. Enforcing mandatory locks requires strict discipline across every client and automation path.

There are also hidden operational traps. If a build engineer adds a new file type to the project but forgets to update the .gitattributes file, 40GB of uncompressed audio will be committed directly into the main branch history. The only fix is a full history rewrite and a forced re-clone for everyone. Furthermore, a lighting artist committing a new 8K skybox every day will cause the LFS bandwidth graph to spike. The monthly cloud bill will arrive, and the studio lead will ask why the repository costs more than the render farm.

Centralized Asset Systems

Centralized systems like Perforce or Unity VCS optimize for the speed of syncing and enforce mandatory file locking. The server is the single source of truth.

These systems are the stronger fit when large binary changes and exclusive checkout are daily work, and the team includes a large proportion of artists. If two artists cannot safely merge a level file, the system must prevent them from editing it at the same time. File locking in Git is a feature you bolt on. File locking in Perforce is a feature you turn off if you do not want it.

The cost model is different. Perforce licenses scale with users, while you pay for your own storage and IOPS. Storing terabytes of historical assets is inexpensive. Serving those assets to 300 developers and 100 build agents simultaneously requires high-end enterprise flash storage and ten-gigabit network switching. When a central server falls over, it is rarely the CPU that maxes out; it is the storage read queues.

Centralized systems also handle remote studios through proxy and edge servers. A proxy intercepts read requests at a remote office and serves cached files over the local network. Write requests always pass through to the master server. This solves the bandwidth problem but creates a systems administration problem. You now have stateful infrastructure sitting in a remote office that needs monitoring, patching, and disk space management. If the proxy goes down, the remote studio stops working.

The Hybrid Trap

Running code in Git and assets in a centralized system sounds clean. In practice, it breaks atomic commits.

If a programmer changes the physics engine code in Git, and a technical artist updates the vehicle models in Perforce to match, the build server has to pull from two places perfectly in sync. When the build breaks, bisecting the error means correlating timestamps across two distinct databases.

The hybrid model has a sync tax. Someone has to keep the two systems aligned and give the build system a single revision to test. That person is usually the build engineer, and the tax is real and ongoing. It works if someone owns the glue. It breaks if nobody does.

The Hidden Users: Build Farms and Remote Studios

Human developers only sync a fraction of the repository. The continuous integration pipeline syncs everything, all the time. Evaluating a version control system based on the desktop client ignores the fact that the majority of repository traffic comes from automated build agents pulling massive workspaces multiple times a day.

A build farm does not care about your branching strategy. It cares about how many bytes it has to move per build. In a centralized system, build agents use persistent workspaces or read-only replicas for fast incremental syncs. In Git, agents clone or fetch, and LFS adds a second download step. If the build farm cannot fetch the repository efficiently, the version control system is the problem, regardless of how the artists feel about it.

Remote studios test the physical limits of your choice. A satellite studio evaluating a vendor’s “fast sync” demonstration will see a warm cache. On their first actual day of production, every first open of a texture will wait on a cross-region download. A warm cache can make a remote-studio pilot look better than a new hire’s first day.

Choosing the System

The decision is driven by team composition and asset volume first, toolchain defaults second, and personal preference last.

Choose Git with LFS when:

• The team is mostly engineers and asset collisions are infrequent.
• The repository is under a few hundred gigabytes and growing slowly.
• The engineering team requires distributed branching and native pull request workflows.
• You have dedicated staff to manage LFS administration, retention policies, and bandwidth costs.

Choose a centralized asset-oriented system when:

• The team is mostly artists and large binary changes are daily work.
• Exclusive editing and file locking are production dependencies.
• The build farm requires high-volume, incremental syncs and persistent workspaces.
• The toolchain (Unreal, Unity, console SDKs) ships with strong default integrations for that system.

Choose the hybrid model only when:

• The engineering team absolutely refuses to abandon Git workflows.
• Asset production has fundamentally different locking and storage requirements.
• You have dedicated release engineering staff to own and maintain the sync bridge between the two systems.

Before finalizing the choice, run a pilot that measures the actual production workload. Measure the time-to-first-clone for a new hire. Measure the build farm’s fetch time for a full workspace. Measure the latency of a remote studio opening a large file after a cache miss. Measure what happens when two artists try to edit the same binary file on the same afternoon.

Migration is a one-way door in practice. Moving from a centralized system to Git is a project. Moving from Git to a centralized system is a project plus a history rewrite or a fresh start. The repository will grow tenfold over the life of the project, and the system you choose today determines whether that growth is a manageable line item or a permanent bottleneck.