Version control for game teams: Git, Perforce or Unity Version Control

The short answer

Small teams and code-heavy projects do well with Git plus Git LFS. Large projects with many artists and very large binary files, especially in Unreal Engine, are better served by Perforce. Unity Version Control sits between them with artist-friendly tools. Whatever you pick, set up large-file handling and file locking from the first day, keep a main branch that always builds, and if you are a client, make sure the repository belongs to you.

Why games are a special case

• Binary assets. Textures, models, audio, scenes and Unreal's asset files cannot be merged line by line. If two people edit the same one, somebody loses their work.
• Size. A project can reach tens or hundreds of gigabytes, far beyond typical software repositories.
• Non-programmers. Artists, designers and audio staff commit every day and need simple tools.
• Generated files. Engines create large caches that must never be committed.

The options compared

Check each vendor's current pricing and limits, which change.

Git with LFS

Git is the tool most developers already know, and hosting services, review tools and build systems all support it. Git LFS stores large files outside the normal history and downloads only the versions you need, which keeps the repository usable.

Set it up properly:

1. Add an ignore file for your engine before the first commit, so caches and build output stay out.
2. Add LFS tracking rules for all binary types before any binary is committed. Fixing this later means rewriting history.
3. Enable file locking for binary types and teach the team to lock before editing.
4. Budget for LFS storage and bandwidth on your host.
5. Give artists a graphical client.

Git suits teams of up to roughly ten to fifteen people on mobile and small PC projects. It strains with very large Unreal projects and many simultaneous artists.

Perforce

Perforce is the long-standing standard at large studios. It handles enormous repositories and files, lets users sync only the parts they need and uses exclusive checkout so two people cannot edit the same binary. Unreal Engine integrates with it closely. The costs are licences beyond the free tier, a server to run or pay for, and administration. Choose it when the project is large, binary-heavy or built in Unreal with a substantial art team.

Unity Version Control

Formerly Plastic SCM, this system was designed with game teams in mind. It offers a simplified interface for artists, strong branching and merging tools for programmers, good handling of large files and integration in the Unity editor. It works with other engines too. Teams who find Git awkward for artists and Perforce heavy to run often settle here.

Practices that matter more than the tool

• Commit small and often, with messages that say what changed and why.
• Lock binaries. Check a scene or asset out before editing, and release it promptly.
• Split large scenes. Use prefabs, sub-scenes or sub-levels so people work on different files.
• Protect the main branch. It should always build and run. Work happens on short branches that are reviewed and merged.
• Automate builds. A server that builds every change catches breakage within minutes. See mobile game performance optimization for adding automated performance checks.
• Keep secrets out. Signing keys, passwords and service credentials belong in a secrets manager, never in the repository.
• Tag releases. Mark exactly what shipped so you can rebuild or patch it.
• Use text formats for assets where the engine allows, which makes changes visible in review.

Branching for games

Long-lived branches that drift apart are painful when binary files cannot be merged. A model that works for most game teams:

Artists often work directly on main with file locks, since their files do not merge anyway.

Backups

Version control is not a backup unless the server itself is backed up. Cloud hosting covers much of this, but keep an independent copy on a schedule and test restoring it. Losing a repository is rare and catastrophic.

For clients who hire a studio

This section prevents the most painful disputes we see.

• Own the repository. Create it in your organisation's account and invite the studio. If the studio hosts, require a full copy at every milestone.
• Check you have everything. The engine project, source art files, build scripts and documentation, not just a final build.
• Hold the keys. Signing keys and store accounts should be yours. Losing a signing key can block updates to your own game.
• Watch the history. Regular commits show real progress between demos.
• Plan the handover. A short document on how to build and release.

These points belong in the contract. See our contract checklist, game IP basics and why outsourcing partnerships fail.

Working with external partners

In co-development, an external team works in the same repository as yours. Give partners access only to what they need, agree branch and review rules, and use the same automated builds for everyone. Clear ownership of folders and files avoids two teams editing the same assets. The alternative, exchanging zip files, loses history and causes overwritten work.

Common mistakes

1. Committing binaries before configuring large-file rules.
2. No ignore file, so caches bloat the repository.
3. No locking, so two artists overwrite each other.
4. A main branch that is often broken.
5. Huge, rare commits that nobody can review.
6. Credentials committed to history.
7. The only copy of the project living on one developer's laptop.

Choosing quickly

Getting help

We set up repositories, large-file rules and automated builds as part of every project, and work inside client-owned repositories. Team extension is described on our co-development page, and packages are on the offer page.

Sources: Git · Git Large File Storage · Perforce Helix Core. Checked November 11, 2026.

Related: Game co-development · Outsource game development · Get a quote