Keep Your Game Team In Sync: Version Control Guide

Most game teams don’t fail at version control because they picked the wrong tool. They fail because nobody actually decided how it works, and then six months in, half the team is working off stale branches, someone force-pushed to main, and the lead programmer is rewriting three days of work at 11pm before a publisher demo.

I’ve watched this happen. I’ve been the person it happened to.

Version control is one of those topics where everyone nods along in pre-production like it’s obvious, and then the actual system falls apart by week four because “we’ll figure it out as we go” is not a policy. So let me tell you what I’ve actually seen work, what the research-and-community consensus looks like (it’s messier than anyone admits), and where the real decisions are.

Git vs. Perforce: The Honest Version

The game industry has a complicated relationship with this question. The indie and mid-size world has largely standardized on Git, usually with Git LFS (Large File Storage) for binary assets. AAA studios, especially ones making games with massive art pipelines, many still run Perforce. Some run both.

I’ll be honest: the Perforce vs. Git debate gets more religious than it deserves. For a team of 2-8 people making a game with a reasonable asset footprint, Git with Git LFS and a host like GitHub or GitLab works fine. It’s cheaper (GitHub’s team plan runs about $4/user/month), the tooling is excellent, and the integration with project management tools like GitHub Projects or Linear is genuinely useful for production tracking.

Where Git starts hurting is at scale. Binary files are not what Git was designed for, and even with LFS, you can run into checkout performance issues if your project has tens of thousands of large textures, audio files, and meshes. Perforce handles massive repositories better, full stop. But Perforce also costs real money (Helix Core’s cloud pricing starts around $25/user/month), has a steeper learning curve, and if you’re a 5-person indie team, it’s probably overkill.

What surprised me was how many mid-size studios (30-100 people) are running Unity projects on Plastic SCM (rebranded as Unity Version Control). It integrates directly into the Unity Editor, which reduces friction for non-programmers significantly. If your whole team is in Unity and you’re fighting with artists who don’t want to touch a terminal, it’s worth a serious look.

The honest answer: pick based on team size, asset scale, and how technical your least-technical team member is. Don’t pick based on what sounds most professional.

Setting Up Branching Strategy Before You Need One

The mistake is waiting until you have multiple people working on the same files before you decide how branching works. By then you’re already in the bad place.

Here’s what I’d actually recommend for most small-to-mid teams. Keep a main (or master) branch that is always in a shippable or at least buildable state. No broken builds on main. This is non-negotiable. Feature development happens on short-lived branches that get merged back in. If a feature takes more than two weeks on its own branch, it’s probably too large, and you need to break it up.

For indie teams, even something this simple is enough. You don’t need Git Flow’s full ceremony with develop branches, release branches, and hotfix branches. That structure was designed for software products with scheduled releases and live maintenance. Games in active development don’t usually match that shape.

What I’d add is a release or candidate branch during your final stretch before a milestone, gold master, or launch. Lock down main as much as you can during that window. Only bug fixes go in. This is where discipline pays off, because the alternative is a scramble where nobody knows what state the build is actually in.

One specific thing worth doing on day one: write a one-page branching guide and put it in the repo’s README. Not a manifesto. Just: what branches exist, what they mean, how you name feature branches (I like feature/username-short-description), and who can merge to main. Takes an hour. Saves weeks.

The Non-Programmer Problem Is Real

Related video

What I *actually* do as a Product Manager (in 2023) · Chloe Shih on YouTube

This is the part most version control articles skip, and it’s where real game teams actually break down.

Artists, designers, and audio folks did not go to school for distributed version control. Asking a texture artist to resolve a merge conflict in a binary PSD file is somewhere between useless and cruel. You need to handle this explicitly.

A few things that actually help:

File locking is underused on Git-based setups. Git LFS supports file locking, and you should turn it on for binary files that genuinely can’t be merged (Photoshop files, audio masters, certain exported formats). Yes, it introduces coordination overhead. That’s better than two people overwriting each other’s work with no way to reconcile it.

GUI clients matter more than programmers think. Something like GitKraken (about $5/month per user) or Fork (one-time $35 license) dramatically reduces the barrier for non-technical team members. If your pipeline requires people to use the terminal for basic commits and pulls, you’re going to get people who just… don’t commit until they have a giant pile of changes. That’s worse than the tool friction you’re trying to avoid.

Asset management workflows inside your engine also matter here. Unity Version Control and Perforce both have editor plugins that let artists check out, lock, and submit files without leaving the tool they’re already in. That’s worth something real.

Commit Hygiene and Why It Matters for Production

Nobody cares about this until they’re debugging something, and then they care a lot.

Commits with messages like “fix” or “stuff” or “wip” are a productivity tax on your future self. When you’re hunting down why a mechanic broke three weeks ago, you want to be able to read the history and actually understand what changed. This isn’t about code purity, it’s about the practical time you’ll spend later.

I enforce a lightweight standard: commit messages should complete the sentence “If applied, this commit will…” So: “Fix jump velocity calculation on slopes,” not “jump fix.” Takes ten seconds. Saves real time in retrospect.

Also, commit often. Small commits are much easier to revert selectively than huge ones. This is one of the few things where the conventional wisdom is just… correct.

Integrating Version Control Into Your Production Process

Sources

• Mikhail Nilov
• what did we actually do. Automate

Version control doesn’t exist in isolation. The best teams I’ve worked with treat their repo history as part of the production record. Commits reference task IDs from their project management tool. GitHub and Jira integrate directly. Linear does too. When a task closes, you can see exactly what changed. That’s useful for postmortems, for QA, and for onboarding new team members who need to understand what happened.

If you’re using Codecks (honestly one of the better tools for indie game producers, starting around $5/user/month), the GitHub integration links commits to cards automatically. Small thing, but it closes the loop between “what did we plan to do” and “what did we actually do.”

Automate your builds off main. Even a simple CI setup through GitHub Actions that builds and runs smoke tests on every merge to main will catch integration issues before they become everyone’s problem. I’ve seen teams resist this because it “adds complexity.” It adds maybe two hours of setup and removes entire categories of build-broken-at-standup situations.

Photo: Mikhail Nilov via Pexels