Version control exists to answer a small set of questions for a team sharing a codebase: what changed, who changed it, and how do two people’s changes get combined without one of them overwriting the other’s work. Git, the system most software teams standardized on, answers those questions by tracking every file as a diff against its previous version, which works well when most changes are small edits to text files. A game studio’s repository is mostly not text files. It’s textures, meshes, audio, animation data and packaged levels, often multiple gigabytes each, and a system built around line-by-line text diffs handles a single large binary file by storing something closer to a full new copy every time it changes, since there’s no meaningful “diff” to compute between two versions of a compressed texture.
Perforce, marketed under the name Helix Core, built its version control model around exactly this problem instead of working around it, and its own case for game development leans on scale and locking rather than diffing: it advertises tracking “everything—from source code to 3D assets—with the speed, scale, and control no other system can match,” and its file-locking model lets a team reserve a binary asset before editing it, so two artists can’t silently overwrite each other’s changes to the same file the way two Git commits touching the same text file might. Perforce also describes support for branching models built around a game’s platform targets, letting a studio “share the same code across different target game platforms” through what it calls Streams, a structured branching approach aimed at the specific problem of maintaining several platform-specific variants of the same project at once. The company states its system is used by the large majority of top studios specifically for this combination: asset scale, locking, and platform branching together.
Studios that prefer Git’s workflow rather than switching systems entirely generally reach for Git LFS, an extension rather than a replacement. Git LFS’s own description of the problem is direct: ordinary Git “replaces large files such as audio samples, videos, datasets, and graphics with text pointers inside Git, while storing the file contents on a remote server,” so the repository itself stays small and fast to clone, while the actual asset data lives in separate storage fetched on demand. The tradeoff is that Git LFS doesn’t solve file locking the way Perforce does natively; a team using it for genuinely large game projects with many artists sharing binary assets is choosing a different set of compromises than a team on Perforce, closer to Git’s branching model but without built-in protection against two people editing the same binary file at once.
Branching itself carries extra weight for a live game, one still being patched and updated after launch, compared to a project that ships once and stops. A studio maintaining a live game typically keeps at least one branch for the version actually running in production, separate from a development branch where the next patch is being built, precisely so an urgent fix to the live game doesn’t have to wait for whatever half-finished feature work is sitting in the main development line. That structure is also what makes a public test realm possible in the first place: a build shipped to a test branch is drawn from a specific, identifiable point in the studio’s branching structure, not from whatever the newest, least-tested code happens to be at the moment someone decides to cut a build.