Every few months a thread appears on a game dev forum asking which version control system studios should use. The responses almost always fall into two camps: programmers who love Git and artists who have had a bad experience with it, and veterans at larger studios who swear by Perforce even knowing its costs.
Both sides are right. That is the honest answer. Git is better at some things. Perforce is better at others. The question is which failure modes your studio can tolerate — and that depends on your team size, budget, and technical capacity.
Where Git Wins
Distributed model and offline work
Git is a distributed version control system. Every clone is a full copy of the repository, including history. You can commit, branch, and review history without a network connection. For a programmer working on a plane or in a coffee shop, this is genuinely useful.
Perforce is a centralized system. Your working copy is a checkout from the central server. Most operations require server connectivity. If the server is down, work grinds to a halt.
Branching and merging for code
Git branching is cheap and fast. Creating a branch takes milliseconds. Switching branches takes seconds. The merge algorithms are mature and handle three-way text merges well. For code-heavy projects or studios where programmers drive the workflow, Git's branching model is genuinely superior.
Perforce branching is more expensive — branching copies files on the server, which is a real operation with real storage cost. The mental model is more complex, and merging streams requires explicit actions that not all team members understand.
Cost and hosting
Git is free and open source. GitHub, GitLab, and Bitbucket offer managed hosting at low cost for small teams. Self-hosting Git is straightforward on standard server infrastructure. For a two-to-ten person indie studio, Git's total cost of ownership is near zero.
Perforce Helix Core licensing is per user and per year. Self-hosting requires dedicated server hardware and someone who knows how to configure and maintain a Perforce server. The free tier is limited to five users and twenty workspaces — fine for a solo developer, tight for any real studio.
Where Perforce Wins
Binary asset handling at scale
Perforce was designed with binary files in mind from the start. It streams only the files you check out, not the entire repository. For a 200GB game repo, checking out the files for your specific task means fetching a fraction of the total data. This is a significant performance advantage over Git, where the default is a full clone of everything.
Perforce also has native delta storage for binary files — subsequent versions of a file store only the differences, even for binary content. Git does not do this. Every binary revision in Git is stored in full.
File locking
Perforce has native, enforced file locking. Check out a file for exclusive edit, and no one else can check it out until you submit. This is not optional or advisory — the server enforces it. For studios working with non-mergeable binary assets, this is essential.
Git has no native locking. Git LFS added an optional locking mechanism, but it is not enforced by default and requires additional server configuration to work reliably.
Changelist management
Perforce organizes commits as changelists — named groups of file changes. You can have multiple pending changelists simultaneously, each containing a different set of changes. This makes it easy to separate "work in progress" from "ready to submit" and to review large changes before they land.
Git's staging area provides some of this, but the workflow for managing multiple simultaneous changesets is more complex in Git, especially for non-technical team members.
The Real Trade-offs
For a small indie studio (under ten people, modest asset sizes), Git with LFS is probably the right choice. The cost is low, the tooling is familiar, and the friction is manageable at that scale.
For a mid-size studio (10-50 people, 50-200GB repos), both options have serious problems. Git starts to crack under binary asset load. Perforce becomes expensive and requires dedicated administration. This is the gap where studios most often find themselves fighting their tools instead of shipping games.
For larger studios (50+ people, hundreds of GB), Perforce is typically the only option that handles the scale — and studios accept its costs because the alternative is worse.
Neither tool was designed with the mid-size studio in mind. That is not a criticism of either project — it is just a real gap in the market. The studio that needs distributed workflows, cheap branching, and native binary asset management at reasonable cost does not have a good answer from either of the traditional options.
That gap is what Diversion exists to address. Not another Git client. Not a Perforce wrapper. A version control system designed around the actual requirements of game development teams at the scale where the existing options stop working.