A solo developer or small indie team has different needs from a 50-person studio. You do not need multi-region replication, dedicated server infrastructure, or an enterprise license. You need to not lose your work, to collaborate with one or two other people without stepping on each other, and to spend as little time as possible thinking about version control.
Here is the honest guide — what you actually need, what you can skip, and what to watch out for as you grow.
Solo Developer
If you are working alone, your version control requirements are simple: you need a history of your project that you can roll back, you need an offsite backup so a hard drive failure does not end your project, and you need it to work with large binary files without too much friction.
Git with a free GitHub or GitLab account covers points one and two. For point three — large binary assets — you have two options: Git LFS (available on both GitHub and GitLab with storage limits on free tiers) or keeping your assets outside version control and backing them up separately.
For a very small project, keeping assets outside version control is not crazy. Keep your code in Git. Back up your art assets to external drive and cloud storage separately. The lack of proper versioning for assets will eventually cost you — when you accidentally overwrite something and cannot get it back — but for a prototype-scale project, it is a reasonable trade against the complexity of setting up LFS.
For anything you are serious about shipping, set up LFS from the start. The setup cost is a few hours. The cost of not having asset history when you need it is much higher.
Two-to-Five Person Team
At two to five people, coordination becomes real. Two people can work on the same level and step on each other. An artist on a contractor basis needs access to the repo but should not be able to accidentally push to main.
Git with GitHub or GitLab remains a solid choice at this scale. The free tiers support multiple contributors. The branch protection and pull request review features are useful even for a small team — not as process overhead, but as a simple "did someone else look at this before it went to main" gate.
What to set up
- Git LFS: Configure it before the repo gets large. After the fact is painful.
- Branch protection on main: Require at least one review before merging. Prevents accidents.
- A .gitignore: Exclude intermediate build artifacts, Unity Library folder, Unreal Intermediate and Saved folders. These regenerate on build and bloat the repo.
- Commit message conventions: Anything more formal than "add X" or "fix Y" is optional at this scale. Just make the message useful enough to understand what the commit did a month from now.
What to skip
- Complex branching strategies. Two people do not need Gitflow. A main branch and short feature branches is enough.
- CI builds. They are useful but setting them up correctly for game projects takes real time. Get your game working first.
- Formal code review processes. A quick look before merging is good. A multi-day review cycle is not appropriate for a team of three.
Five to Fifteen People
At this size, the limitations of basic Git start to matter. More people means more simultaneous work on shared assets. LFS bandwidth costs accumulate. The occasional scene file conflict becomes a weekly event rather than a monthly one. An artist who does not know the terminal hits friction more often.
The main decisions at this stage:
Do you need file locking?
If you have non-technical contributors working on binary assets in Unity or Unreal, the answer is probably yes. The manual discipline required to avoid conflicts without locking breaks down at this team size. Set up LFS locking, and if possible, use a tool that exposes lock status inside the engine editor rather than requiring CLI interaction.
Do you need dedicated infrastructure?
Probably not yet. Managed GitHub or GitLab with LFS storage add-ons is usually cost-effective up to this team size. Where you outgrow managed hosting is when your repo size exceeds what the storage add-ons can reasonably serve, or when your LFS bandwidth costs become material. Track both as you grow.
Should you evaluate Perforce?
Perforce makes sense at this scale if most of your team is non-technical and the command-line requirement for Git is a consistent pain point, or if your asset repo is already large enough that Git LFS checkout times are hurting productivity. The cost — financial and operational — is real. Evaluate it honestly against the Git friction, not as a prestige signal.
The Universal Rules
Regardless of team size or tool choice, a few things always apply:
- Commit frequently. Small commits are easier to understand and easier to revert if something goes wrong.
- Commit working states. Do not commit code that does not compile or assets that are half-finished. If you need to save work-in-progress, use a personal branch or a stash, not main.
- Test your restore path. At least once, delete a recent file and practice recovering it from version control. If you cannot do it quickly, you do not actually have version control — you have version storage.
- Know your backup status. Version control is not a backup. If your hosting provider deletes your account or shuts down, you need another copy. A remote Git remote is a backup only if you maintain it separately from your main remote.
The tooling you choose matters less than the habits you build. A team that commits reliably to a simple Git setup ships more work than a team with sophisticated infrastructure that nobody follows correctly.