Summary
Source control, also called version control, is the system a team uses to track changes, collaborate safely, and recover from mistakes. Students usually reach this page through questions like “should I use Git or Perforce for Unity?”, “what is Unity Version Control?”, or “why do game teams need source control at all?” The short answer is that source control is non-optional on any serious project: without it, teams overwrite work, lose history, and cannot recover cleanly when something breaks.
For the mechanics of using Git, see git-concepts, git-workflow, git-branching, and git-github-unity.
Why source control is a production essential
Without source control on a team project, the following problems are not edge cases — they are inevitable:
- Overwritten work. Two people edit the same script and share it via email or cloud storage. The second person’s version overwrites the first. One person’s work is gone.
- No rollback. A change breaks something. Without history, the only option is to remember and manually undo. If the break was introduced three days ago and nobody noticed, there is no clean state to return to.
- No accountability. On a professional project, every change needs to be traceable — who made it, when, and why. This matters for debugging, for handovers, and for post-mortems.
- Fear of experimentation. Without the ability to revert, developers become cautious about trying things. Source control makes it safe to experiment because every change is reversible.
The principle is the same as in agile-design: a playable, version-controlled project at all times is more valuable than untracked work-in-progress.
The challenge: games have large binary files
Source control systems were originally designed for text-based source code. Game projects are fundamentally different: they contain large binary files that cannot be diffed or merged line by line.
| File type | Size range | Diffable? |
|---|---|---|
| C# scripts | KB | Yes — plain text |
| Unity scene files | 10s–100s of KB | Partially (YAML text format) |
| Prefab files | KB–MB | Partially (YAML text format) |
| Textures (.png, .psd) | MB–100s of MB | No |
| Audio files | MB–100s of MB | No |
| 3D models (.fbx, .blend) | MB–100s of MB | No |
| Compiled builds | 100s of MB–GB | No |
The core tension: Git was built for text code, but games are mostly binary art assets. Managing this tension is the main practical concern when choosing and configuring source control for game development.
Source control options
Git + GitHub (recommended for indie and student teams)
What it is: Git is a distributed version control system. GitHub is a cloud hosting service for Git repositories. Together they form the dominant stack for indie developers and open source projects.
Strengths:
- Free for public and private repositories (GitHub free tier)
- Industry-standard tool — used at virtually every indie studio and tech company
- Excellent branching model — feature branches are lightweight and cheap
- Large community and documentation
- GitHub Pull Requests provide code review workflows
- GitHub Desktop provides a GUI for those who prefer not to use the command line
Weaknesses:
- Not designed for large binary files — committing textures and audio bloats the repository
- Merging Unity scene and prefab files requires care (see git-branching)
- Command line can be intimidating for non-programmers on the team (artists, designers)
Best for: Student projects, indie teams, projects where scripts and logic are the primary concern, or any team comfortable with the command line.
Git LFS (Large File Storage): An official Git extension that stores large binary files separately from the main repository, replacing them with lightweight pointer files. Supported by GitHub (1 GB free storage; paid plans available). Use Git LFS if your repository is growing beyond a few hundred MB because of art assets.
# Install Git LFS, then tell it to track texture and audio files:
git lfs install
git lfs track "*.png"
git lfs track "*.psd"
git lfs track "*.wav"
git lfs track "*.mp3"
git lfs track "*.fbx"
git add .gitattributes
Perforce Helix Core (industry standard at professional studios)
What it is: A centralised version control system designed specifically for large binary-heavy projects. The dominant VCS at AAA game studios — used at EA, Activision, Epic Games, Naughty Dog, and most major publishers.
Strengths:
- Handles large binary files natively and efficiently — no special configuration needed for textures and audio
- Scales to teams of hundreds managing repositories of hundreds of gigabytes
- File locking system prevents two people editing the same binary file simultaneously (critical for art assets that cannot be merged)
- Direct Unity Editor integration via P4 plugin
- Free tier available: Helix Core is free for up to 5 users and 20 workspaces
Weaknesses:
- Requires a server (either self-hosted or cloud-hosted via Helix TeamHub/p4 cloud)
- More complex setup than Git + GitHub
- Centralised model means you need network access to commit (no offline commits)
- Less familiar to developers coming from open source backgrounds
- Overkill for small student projects
Best for: Medium-to-large teams with significant art assets, professional productions, situations where file locking is essential (multiple artists working on large assets), or as preparation for industry roles where Perforce experience is expected.
File locking in Perforce: Because binary files cannot be merged, Perforce supports exclusive file checkout — if an artist has a texture open, Perforce can prevent a second person from editing it simultaneously. This is a significant practical advantage over Git for art-heavy teams.
Unity Version Control (formerly Plastic SCM)
What it is: A version control system acquired by Unity Technologies in 2020 and integrated directly into Unity Hub and the Unity Editor. Previously sold as Plastic SCM; now available under the Unity DevOps umbrella.
Strengths:
- Deep Unity Editor integration — merge conflicts for scenes and prefabs are handled visually within Unity itself, rather than requiring manual YAML editing
- Designed specifically for game development workflows, not general software development
- Branch and merge model with good support for binary files
- Free tier available for small teams (up to 3 seats on cloud)
Weaknesses:
- Smaller community and ecosystem than Git
- Less relevant for non-Unity work — learning it does not transfer as broadly as Git knowledge
- Pricing and tier structure has changed since Unity’s 2023 monetisation changes — check current plans before committing
- Less commonly taught in tutorials and educational resources
Best for: Unity teams that struggle with scene and prefab merge conflicts, teams where non-programmers need to participate in version control, or teams already in the Unity ecosystem who want the tightest possible integration.
SVN (Apache Subversion)
What it is: An older centralised version control system. Predates Git, widely used in the mid-2000s through early 2010s.
Strengths:
- Simpler conceptual model than Git (centralised, no distributed branching)
- Still used at some studios and in some legacy pipelines
- Handles binary files better than plain Git (though not as well as Perforce)
Weaknesses:
- Largely superseded by Git for new projects
- Branching is clumsy and slow compared to Git
- Fewer modern hosting options and integrations
- Learning it offers less career value than Git
Best for: Legacy projects already using SVN, or teams specifically needing a simple centralised model without the complexity of Perforce.
Comparison summary
| System | Cost | Binary files | Merge model | Best team size | Industry use |
|---|---|---|---|---|---|
| Git + GitHub | Free | Poor (use LFS) | Distributed | 1–20 | Indie, tools, web |
| Git + LFS | Free / paid | Good | Distributed | 1–20 | Indie, small studio |
| Perforce Helix Core | Free ≤5 users | Excellent | Centralised | 5–500+ | AAA, mid-size studio |
| Unity Version Control | Free ≤3 users | Good | Distributed | 1–10 | Unity-specific teams |
| SVN | Free | Moderate | Centralised | 1–50 | Legacy projects |
Recommendations by context
Student project (1–5 people, Unity, mostly scripts):
Use Git + GitHub. Set up the Unity .gitignore correctly from day one (see git-github-unity). Avoid committing art assets over 10 MB without Git LFS.
Student project (1–5 people, Unity, significant art assets): Use Git + GitHub + Git LFS, or consider Unity Version Control for better scene merge handling. Define clear ownership of scenes and large assets to minimise conflicts.
Graduate placement or industry internship: Expect to use Perforce at a mid-to-large studio. Git at a small studio or tools team. Understand both. The concepts transfer — branching, committing, merging, reverting are universal regardless of which tool implements them.
Solo developer: Git + GitHub for cloud backup and history. Even for solo work, source control protects against accidental deletion and hard drive failure.
Source control as a production discipline
Source control is most effective when the whole team follows consistent habits. Technical setup is only part of the solution — the workflow agreements matter equally.
Commit discipline:
- Commit small, logical units of work — not “everything I did today”
- Write meaningful commit messages describing what changed and why
- Do not commit broken builds to the main branch
- See sprints for how commit cadence maps to sprint structure
Branch strategy:
- Use a
mainbranch that is always in a shippable state - Create feature branches for new work; merge when complete and tested
- See git-branching for the mechanics
Communication:
- Announce to the team before editing shared assets (scenes, shared prefabs, audio files)
- Use Pull Requests or equivalent code review for significant changes
- The agile-design principle of “keep a working game at all times” depends on source control discipline
This is also why source control connects directly to build-and-release-management and qa-and-bug-triage: reliable builds, reproducible regressions, and safe hotfixes are much harder without trustworthy history and disciplined branching.
Unity-specific workflow note
Unity’s newer production guidance makes a useful distinction between version control as the underlying system for tracking file history and source control as the broader day-to-day collaboration discipline around project organisation, file ownership, and branch hygiene. In practice, the distinction matters less than the workflow choice, but it reinforces a good habit: teams should decide early how they will structure folders, handle large binary assets, and avoid editing the same scenes or prefabs at the same time. Unity’s current material treats Git, Perforce, and Unity Version Control as the main practical options, with smart locks and stronger binary-file workflows becoming more important as art-heavy collaboration increases. (Unity, Best practices for project organisation and version control, see source-unity-project-organisation-version-control)
Related
- git-concepts — how Git stores data; snapshots and three states
- git-workflow — daily Git commands; Unity .gitignore
- git-branching — feature branches and conflict resolution
- git-github-unity — GitHub setup, collaborators, Pull Requests
- agile-design — production principles that depend on working version-controlled builds
- scrum-in-game-development — team workflow context
- source-unity-project-organisation-version-control
- minimum-viable-game — keeping the main branch shippable
- source-progit