Stephen Brenish
Most game studios get this decision wrong not because they lack information, but because they benchmark against the wrong kind of project.
Teams that migrate from Git to Perforce mid-production can lose weeks to the disruption. Teams that insist on Perforce for a three-person project can spend just as long building infrastructure they never needed. The version control question is genuinely one of the most consequential early calls you make, and the internet is full of confident takes from people who’ve only worked one side of the fence.
The right answer depends on factors most comparisons skip: your engine, how much of your project is binary art, and who on the team will own the server.
Why This Comparison Is Harder Than It Looks
Git and Perforce aren’t just different tools. They’re built on fundamentally different assumptions about how people work.
Git is distributed. Every developer has a full copy of the repository history locally. That’s elegant for code-heavy projects, awful for a 200GB texture library. Perforce P4 (called Helix Core until Perforce’s 2025 rebrand, and you will still see both names in job listings) is centralized. There’s one server. Developers check out files, lock them if needed, and check them back in. The server knows who has what.
That locking behavior isn’t a limitation. For game dev, it’s often the whole point.
Binary assets are the crux of this. Git can store binary files, but it handles them badly. Every time you change a PSD or a Maya scene, Git stores the entire new version. A 50MB texture touched 20 times? That’s potentially a gigabyte of history just for one file. Git LFS (Large File Storage) exists to solve this, and a lot of studios use it, but it doesn’t give you file locking natively in a way that prevents two artists from overwriting each other’s work on the same asset. You need Git LFS + additional configuration to approximate what Perforce does out of the box.
Perforce has exclusive checkout. Artist A locks character_hero_v001.fbx. Artist B tries to open it, gets a notification that it’s locked. No merge conflict. No “who’s version do we keep.” This alone is why you’ll find Perforce at essentially every AAA studio making games with large art teams.
Where Git Actually Wins
I want to be fair here because the “AAA uses Perforce therefore Perforce is better” logic is sloppy.
Git is genuinely better for branching workflows. Branching in Perforce exists, but historically it’s been heavier and slower to work with compared to Git’s lightweight branching model. If your team is doing a lot of feature branches, hotfixes across branches, or code-heavy work (systems programmers, engine teams), Git’s branching and merging is noticeably more fluid.
Git is also free and self-hostable via GitLab, Gitea, or just GitHub for small repos. Perforce’s Helix Core has a free tier: 5 users, 20 workspaces. Beyond that, you’re paying for licenses. Commercial pricing is quote-based rather than a simple public price list, so get a quote before you budget. Per-seat licensing adds up quickly for a 20-person indie.
Many mid-sized studios run a hybrid: Perforce for art assets and binary files, Git for pure code repositories, with some integration layer stitching them together. Unreal Engine projects in particular sometimes use this setup because Unreal’s own tooling has historically played better with Perforce, though Git support in Unreal has improved.
Unity teams have a third option. Unity Version Control (formerly Plastic SCM) supports both a distributed, Git-like workflow for programmers and file locking for artists, and it integrates with the Unity Editor. If you are on Unity, evaluate it alongside Git LFS and Perforce.
The Unreal Situation Specifically
If you’re building in Unreal Engine, you need to think about this more carefully than Unity developers do.
Unreal’s asset files (.uasset, .umap) are binary. You cannot merge them in a text editor. You cannot resolve a conflict by looking at a diff. If two people edit the same map file simultaneously in Git without locking, one of them is losing their work. Full stop.
Epic’s own recommendation (as of 2026) leans toward Perforce with Helix Core, and they ship built-in Perforce integration in the editor. You can use Git with Unreal, but you’re fighting the grain of the engine slightly, and you need to be disciplined about Git LFS configuration and file locking. Teams that skip that discipline pay for it later.
Which setup fits which team
| Team and project | Setup that usually fits | Why |
|---|---|---|
| Small, code-heavy team on Unity or Godot | Git with Git LFS for large binaries | Free, familiar, lightweight branching; little binary contention |
| Unity team with a growing art pipeline | Unity Version Control, or Git LFS with locking configured | Locking for artists without giving up programmer workflows |
| Unreal project with a real art team | Perforce P4 | Exclusive checkout for .uasset and .umap files, built-in editor integration |
| Mid-size studio with separate code and content | Hybrid: Perforce for content, Git for services and tools | Each tool where it is strongest, at the cost of maintaining two systems |
Whatever you choose, decide before production starts. Migrating version control mid-project is one of the most disruptive changes a team can make.
The Setup Cost Nobody Talks About
Here’s where studios make a painful mistake. They pick a tool based on features, then wildly underestimate setup and maintenance cost.
Perforce server administration is a real skill. Someone on your team needs to own it, configure typemaps correctly (this determines how Helix Core handles binary vs text files, and getting it wrong causes problems you won’t catch until you’re deep in production), set up regular checkpoints and backups, and manage workspace configurations. It’s not brutal, but it’s not zero. If you’re a small team without a dedicated technical director or DevOps person, budget time for this or hire someone who’s done it before.
Git, especially through GitHub or GitLab, has a much lower floor for initial setup. The ceiling for complex configurations (monorepos, LFS at scale, branch protection rules) can get involved, but most small teams can be up and running in an afternoon.
Budget for it honestly. A first Perforce server for a small team can take days of a technical lead’s time to configure properly, between typemaps, permissions, backups and workspace setup. That is time not spent on the game, so plan it into pre-production rather than discovering it in month three.
Sources
- Perforce Helix Core documentation (current): Official guidance on typemaps, workspace configuration, and binary file handling at perforce.com
- Git LFS documentation (current): GitHub’s official specification for large file storage behavior and limitations, including known constraints on file locking
- Epic Games Unreal Engine Source Control documentation: Epic’s current recommendations for version control integration, available at docs.unrealengine.com
- Perforce: Introducing the P4 Platform (2025 rebrand of Helix Core)
Photo: cottonbro studio via Pexels
