When I started consulting a year and a half ago, I never expected one of my most common recommendations would be this simple: “Do you have working source control?” And no, your Google Drive or an external hard drive does not count as source control.
It’s honestly surprising how many teams I’ve met who are building games without any version control at all. And yes, it’s possible to make a game that way. That’s how development was done more than 20 years ago. But today we have far better tools, and skipping source control just adds unnecessary complexity to something already difficult: shipping a game.
This article is written mainly from a developer’s perspective. Artists, designers, and QA all feel the effects of source control, but my background is on the programming side. If you don’t currently have source control in place, I strongly encourage you to put it at the very top of your priority list.
Why Source Control Should Be Priority #1
Without source control:
-
Files get lost or overwritten.
-
Hotfixes are risky because you can’t roll back safely.
-
Collaboration slows down as everyone tries to work around each other’s changes.
-
You run a higher risk of code misplacement, since there’s no reliable submission history to verify changes.
-
If everything lives on a single machine, you risk losing all progress if that machine is stolen or corrupted.
With source control:
-
Every change is tracked, reversible, and attributable.
-
Hotfixes can be made quickly without breaking ongoing work.
-
The entire team has a safety net that makes experimentation less risky.
If you don’t have version control in place, stop here and make it your first infrastructure task.
The Big Three Systems
SVN (Subversion)
-
Pros: Centralized and easy to set up. Great for small teams who want something straightforward.
-
Cons: Branching and merging aren’t as smooth as modern alternatives. Distributed teams will feel its limitations quickly.
-
Discipline factor: Just like Perforce, SVN forces you to update before committing, which means conflicts must be resolved upfront. This can slow you down but keeps the repo clean.
Git
-
Pros: Decentralized (works offline), huge ecosystem, and branching is cheap. You can spin up feature branches, hotfix branches, or experimental branches without slowing down.
-
Rebasing and merging are powerful, especially for projects like Unity where
.assetfiles are stored in text format—making diffs human-readable. -
Cons: Binary assets (like Unreal blueprints) don’t play nice with Git. Without LFS (Large File Storage), repositories can get bloated and merges painful.
Perforce
-
Pros: Authoritative by design. You must keep files in a good state before submitting. Perforce requires you to update and clean merges before check-in, which enforces discipline. It also handles binary assets extremely well, making it a go-to for Unreal projects.
-
Perforce Streams: A structured branching system (mainline, dev streams, release streams) that gives teams an orderly framework for scaling.
-
Cons: Requires infrastructure setup and has a steeper learning curve. For small indie teams, it can feel heavy, but it shines for larger groups or asset-heavy pipelines.
Not sure if your project is technically ready?
Take our free Technical Check Quiz and find out where your setup stands.
Large File Storage & Repo Management
One of the biggest headaches in Live Ops is the size of modern game projects. Pulling down 200 GB of data every time you set up a new machine isn’t realistic. Luckily, all three systems have solutions:
-
Git LFS: Lets you track large binary assets without bloating the core repo. Essential for mixed projects with heavy art.
-
Perforce Streams & Partial Sync: Streams give order to your branching, and partial sync means team members only pull the files they need.
-
SVN Sparse Checkouts: A less elegant but still effective way to avoid downloading everything.
The key principle: developers should only sync what they need to work, not the entire project.
A Note on Team Responsibility
While this guide is written mainly for developers, source control isn’t just a programming concern. Artists, designers, producers, and QA all rely on version control to keep the project stable. Choosing the right system and configuring it properly is a responsibility that affects the entire team, not just programmers.
Closing Thoughts
Source control is the backbone of Live Ops. If your team doesn’t have it in place yet, make it your top priority before tackling more advanced workflows like builds or testing.
And if you’re looking for help setting up or improving your pipeline, our Technical Consulting services can support you with source control, builds, testing, and beyond.
FAQ: Source Control in Game Development
Isn’t Google Drive or Dropbox enough for version control?
No. While they store files, they don’t track history in a reliable, developer-friendly way. There’s no branching, merging, or blame tracking. They also don’t prevent conflicts when multiple people edit at once.
Which system is best for my project: SVN, Git, or Perforce?
It depends on your team size and workflow:
-
SVN is simple and fine for very small teams.
-
Git is flexible and great for Unity projects with mostly text-based assets.
-
Perforce is the industry standard for asset-heavy or Unreal projects.
The best approach is to evaluate your pipeline needs before committing.
How do I handle large assets in Git?
Use Git LFS (Large File Storage). It prevents large binary files from clogging your repo. Without it, Git performance will degrade as assets pile up.
What are Perforce Streams, and why do they matter?
Streams are a structured branching model in Perforce. They keep mainline, dev, and release work organized, reducing merge chaos and making large-team workflows much easier.
My project is already underway without source control. Is it too late?
Never. The sooner you introduce source control, the safer and more efficient your development becomes. Migrating may take effort, but the cost of continuing without it is much higher.
Do non-programmers really need access to source control?
Yes. Artists, designers, and QA all rely on version stability. Developers usually set up the system, but it should support the entire team.
