How to Use Unity Version Control (Formerly Plastic SCM): Setup, Branching, and Large Files

Git is the right answer for most developers most of the time. The Git guide earlier in this series explains why: it is free, widely understood, works with every tool in the ecosystem, and the hosting options are abundant. But there are two situations where Git starts causing real friction in Unity projects, and Unity Version Control exists specifically to address both of them.

The first is large binary files. Git tracks text changes efficiently. A modified .fbx or .psd file is not a text diff — it is an entirely new binary blob, and Git stores both the old and new version forever. A Unity project with a year of texture and mesh history can balloon to gigabytes in ways that slow clones, push times, and storage costs in ways Git LFS only partially addresses.

The second is artists on the team. Git's branching model is logical once you understand it, but it is not intuitive for non-programmers. An artist who needs to edit a scene file and does not know whether someone else has it open is one accidental overwrite away from a bad day. Unity Version Control's Smart Locks lets a team member lock a file before editing it, preventing others from making conflicting changes until the lock is released — a workflow that makes sense to artists who are used to checking files out of a shared drive, not merging divergent histories.

Unity Version Control, previously named Plastic SCM, was acquired by Unity in 2020 and is now part of Unity DevOps. If you have heard it called Plastic SCM, UVCS, or Unity DevOps Version Control — they are all the same product at different points in its naming history.

A Real Scenario Where This Matters

Three people working on a Unity project: a programmer, a 3D artist, and a level designer. The programmer uses Git comfortably. The 3D artist has never used version control before. The level designer edits scenes in Unity.

With Git: the artist keeps forgetting to pull before pushing, the level designer's scene merges produce conflicts in Unity's binary YAML format that are nearly impossible to resolve manually, and every time someone adds new textures the repository gets measurably slower to clone.

With Unity Version Control: the artist uses Gluon — UVCS's simplified interface designed specifically for artists and non-technical team members — which shows only their checked-in files and pending changes without exposing branch topology or merge concepts. The level designer locks scenes before editing them so nobody else can touch them simultaneously. Binary files are stored efficiently without the compounding history problem Git has.

This is not a hypothetical. It is the exact situation UVCS was designed for. Whether it is the right tool for your project depends heavily on whether you are in this situation or not.

Pricing: What Changed in March 2026

As of March 1, 2026, Unity updated Unity DevOps pricing significantly. The new structure includes unlimited seats for cloud-hosted Unity Version Control — no more per-seat charges — plus 25GB of free storage (five times the previous 5GB limit) and 100GB of free egress per month. Usage beyond those free tiers is pay-as-you-go per GB.

This is a meaningful change. The previous model charged per seat after the first three users, which made UVCS expensive for teams of five or more. Unlimited seats at the free tier makes it genuinely viable for small and medium teams at no monthly cost, provided you stay within 25GB of storage.

25GB goes faster than it sounds for a Unity project with high-resolution textures, audio files, and FBX meshes. A single AAA-quality character with textures can be several hundred MB. Keep an eye on storage usage in the Unity Cloud Dashboard and plan your asset pipeline accordingly — compressing textures before committing and keeping large reference files outside the repository where possible.

Tier	Seats	Free Storage	Free Egress	Overage
Free	Unlimited	25 GB	100 GB/month	Pay-as-you-go per GB
Unity DevOps (paid)	Unlimited	Increased per plan	Increased per plan	Reduced per-GB rate

Verify current overage rates at unity.com/features/version-control — the per-GB pricing changes and the official page is the authoritative source.

Part 1: Setup and Installation

Creating a Repository

1. Go to cloud.unity.com and sign in with your Unity ID.
2. Create or select an organization.
3. Go to DevOps > Version Control.
4. Click Create Repository, give it a name matching your project, and confirm.

Installing the Client

Unity Version Control can be used from within the Unity Editor, as a standalone desktop client, or on Linux. For most developers, using it from within the Unity Editor is the fastest way to get started.

In Unity, go to Edit > Project Settings > Version Control. Set the Mode dropdown to Unity Version Control. Unity installs the necessary package and adds a UVCS panel to the editor.

Alternatively, download the standalone Unity Version Control desktop client from the Unity DevOps page for a full-featured interface outside the editor. The desktop client is worth installing even if you primarily work inside Unity — it provides better branch visualization and conflict resolution tools than the in-editor panel.

Connecting to Your Repository

1. In the Unity editor's UVCS panel (or the desktop client), sign in with your Unity ID.
2. Select the organization and repository you created.
3. Choose a local workspace location — the folder on your machine where the repository files will live.
4. Click Create Workspace.

Your project files now exist both in the Unity project folder and tracked by UVCS. The first checkin is next.

Part 2: The Daily Workflow

UVCS uses different terminology from Git, which trips people up when switching. The concepts map closely — the words are just different.

Git Term	UVCS Term	What It Means
Commit	Checkin	Save a snapshot of changes to the repository
Commit hash	Changeset	A numbered snapshot of changes at a point in time
Push	Push (same)	Send local changesets to the cloud repository
Pull	Update / Sync	Get latest changes from the cloud to local workspace
Branch	Branch (same)	An independent line of development
Staging area	Pending Changes	Changes ready to be included in the next checkin

Checking In Changes

1. In the UVCS panel inside Unity (or the desktop client), you will see Pending Changes — files that have been modified since the last checkin.
2. Review the list. Select the files to include in this checkin.
3. Enter a comment describing what changed.
4. Click Checkin.

The checkin is local by default — it saves to the local repository. To push to the cloud, click Push in the toolbar. In practice, most developers check in and push in the same action by using the combined Push button.

Updating From the Cloud

Before starting work each session, sync to get the latest changes from your team:

1. Click Sync / Update in the UVCS panel or desktop client.
2. UVCS downloads any changesets pushed by other team members since your last sync.
3. If there are conflicts, UVCS shows them in a conflict resolution window — described in the troubleshooting section below.

Part 3: Branching and Task Branches

UVCS handles branching similarly to Git but with a workflow that maps more naturally to how game teams actually work — particularly through task branches.

Creating a Branch

1. In the Branch Explorer (desktop client: View > Branch Explorer), right-click the branch you want to branch from (usually main).
2. Select Create Branch.
3. Name it descriptively: task/add-enemy-patrol, fix/jump-height-bug.
4. UVCS switches your workspace to the new branch.

Merging Back to Main

1. Switch to the main branch.
2. Right-click your task branch in the Branch Explorer.
3. Select Merge.
4. UVCS shows a merge preview. Confirm and the changes integrate into main.

The Branch Explorer's visual tree is one of UVCS's genuine advantages over Git for developers who are not comfortable with command-line branching. Seeing the branch history as a graphical tree rather than as terminal output makes the state of the repository immediately readable for the whole team, including non-programmers.

Part 4: Smart Locks for Artists

Smart Locks is UVCS's file locking system. When a team member locks a file, others are prevented from making conflicting edits until the lock is released — even across branches, where the lock travels until it reaches the destination branch and the change is merged.

This is specifically valuable for Unity scene files, large textures, and audio files — binary assets where a merge conflict means "two people both changed this file and there is no way to automatically combine the results."

Locking a File

1. In the desktop client, right-click a file in the workspace.
2. Select Lock.
3. The file is now locked to your user. Others attempting to check in changes to the same file see a warning that it is locked.

The Gluon Interface for Artists

Gluon is UVCS's simplified interface designed for artists and other non-technical team members. It shows only the files in the workspace without exposing branch topology, changeset history, or merge concepts. The Gluon workflow is: update to get the latest files, lock the file you are about to edit, make your changes, check in. That is the entire workflow non-programmers need to know.

Pointing artists at Gluon rather than the full UVCS client removes most of the friction that comes from asking non-programmers to use version control at all.

UVCS vs Git: Which Should You Use

This is the honest version of the comparison, not the marketing version.

Factor	Git + GitHub/GitLab	Unity Version Control
Setup time	Fast — widely documented	Moderate — Unity account and cloud setup required
Large binary files	Needs Git LFS, still has limitations	Native, efficient, no LFS setup
Artist-friendly workflow	Steep learning curve	Gluon makes it accessible to non-programmers
File locking	Git LFS locks, limited	Smart Locks, robust and branch-aware
Unity Editor integration	Via third-party plugins	Native, built into the editor
Ecosystem / tooling	Enormous — GitHub Actions, CI/CD, code review tools	Unity-specific — less third-party tooling
Cost (small team)	Free on GitHub	Free up to 25GB storage
Cost at scale	Varies by host	Pay-as-you-go per GB over 25GB
Best for	Solo developers, programmer-only teams, open source projects	Teams with artists, projects with large binary assets, studios wanting Unity-native workflow

The honest answer for a solo programmer: Git is probably still the right choice. The Git guide and GitHub Actions guide earlier in this series cover a workflow that is free, well-documented, and integrates with more external tools than UVCS does.

The honest answer for a team with artists who struggle with Git, or a project pushing large textures and audio regularly: UVCS is worth the switch. Smart Locks and Gluon solve real problems that Git LFS only partially addresses.

Common Mistakes

• Checking in Unity's Library folder. The Library folder is generated by Unity from your source assets — it is large, machine-specific, and should never be in version control. Add a .uvcsignore file (equivalent to .gitignore) at the root of the workspace and exclude Library, Temp, and Logs before the first checkin.
• Not syncing before starting work. Checking in changes on top of stale local files creates conflicts that would not have existed if you had pulled the latest changesets first. Sync at the start of every work session, not just when something breaks.
• Forgetting to release locks. A locked file that nobody is actively editing blocks the whole team from touching it. Release locks as soon as the file is checked in. Set a team convention that locks must be released within a reasonable window — leaving files locked across weekends is a recurring source of friction.
• Committing with no comment. A changeset with no comment is useless for understanding project history. Even "Fix player jump height" is better than nothing. Make descriptive comments a team requirement from day one.
• Exceeding 25GB storage without planning. The free tier is generous but Unity projects with large asset libraries fill it. Monitor storage usage in the Unity Cloud Dashboard regularly and establish a convention for what assets belong in version control versus external storage before you hit the limit unexpectedly.

Troubleshooting

Merge conflict on a Unity scene file.

Scene file conflicts are the most painful kind — Unity's YAML scene format is technically mergeable but practically difficult. The best fix is prevention: use Smart Locks on scene files so only one person edits them at a time. For a conflict that has already happened, UVCS's visual merge tool shows both versions side by side. For scene files specifically, picking one version entirely (theirs or mine) is usually less painful than trying to merge line by line.

Workspace shows files as changed that you did not touch.

Unity regenerates certain files automatically — project settings, package manifests, generated meta files — when the editor opens or imports assets. Check whether the "changed" files are ones you actually modified or Unity auto-generated changes. If they are auto-generated, either add them to .uvcsignore or check them in as part of a housekeeping changeset so the workspace stays clean.

Push fails with an authentication error.

Your Unity ID session has likely expired. Sign out and sign back in through the UVCS panel or desktop client. If the issue persists, check whether your Unity organization's permissions still include access to the repository — organization administrators can revoke access without the affected user being notified immediately.

Storage usage growing faster than expected.

Check the Unity Cloud Dashboard's storage breakdown by repository. Large spikes usually come from accidentally committing generated files (Library, Temp), binary assets that should be compressed before committing, or keeping too many large historical versions of frequently-changed textures. Compressing textures before committing and enforcing the .uvcsignore file for generated folders prevents most runaway storage growth.

Action Steps

1. Create a Unity ID and sign into cloud.unity.com if you do not already have an account.
2. Create a new UVCS repository for your current Unity project.
3. Connect via the Unity Editor's Project Settings > Version Control panel.
4. Create a .uvcsignore file excluding Library, Temp, Logs, and any other generated folders before making the first checkin.
5. Do a first checkin of the entire project with a comment like "Initial checkin — project setup."
6. If working with a team: add each member, have artists install Gluon, and establish a locking convention for scene files before anyone starts parallel work.

Next Topics To Learn

• Git and GitHub for Beginners — if you are a solo developer or programmer-only team, the Git guide covers the simpler and more widely supported alternative with the same core version control concepts.
• GitHub Actions for Beginners — automated build pipelines that connect to your version control workflow, covering the CI/CD side of what Unity DevOps Build Automation also provides.
• Unity Android Build Setup Guide — once version control is in place, the next production concern is the build pipeline — Android and iOS build configuration covered in those guides.