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.
  

How to Use Unity Addressables: Fix Build Size, Memory, and Asset Loading for Beginners

There is a specific moment in most Unity projects when asset management stops working. You have been using the Resources folder since day one because it is simple — put a prefab in Resources, call Resources.Load, done. Then you add a few hundred assets, your build size balloons, your load times get worse, and you start noticing that Unity loads everything in Resources at startup whether the current scene needs it or not.

That is when most developers search for "Unity Addressables" for the first time.

Addressables is Unity's answer to the Resources folder problem. It provides a way to load assets by a string address — like a key — rather than a direct reference, supports asynchronous loading from any location, and handles dependency management and memory counting automatically. The setup is more involved than Resources.Load, but the tradeoff is real control over what is in memory, when it loads, and where it comes from.

This guide covers the full beginner path: installing the package, marking assets as addressable, loading them in code, releasing memory correctly, and understanding Groups well enough to make sensible decisions about your project's asset structure.

Resources Folder vs Addressables: The Real Difference

Before touching any Addressables setup, understanding why the Resources folder falls apart at scale saves you from second-guessing the switch later.

When you put an asset in a Resources folder, Unity includes it in the build unconditionally. Every texture, prefab, and audio clip in Resources gets packed into the game regardless of whether a player ever reaches the content that uses it. On mobile especially, this punishes your build size and your startup memory without any benefit to players who never trigger those assets.

Addressables loads assets on demand. Only the assets your code explicitly requests get loaded, and only when they are requested. Assets can live locally in the build, or remotely on a server, and the loading code is identical either way. That last part is what makes Addressables worth the setup cost for projects planning any kind of content delivery beyond the initial install.

Area	Resources Folder	Addressables
Asset loading	Synchronous, blocks main thread	Asynchronous, non-blocking
Build inclusion	Everything in Resources, always	Only what is explicitly loaded
Memory management	Manual, easy to leak	Reference counted, explicit release
Remote content	Not supported	Built-in, same code as local
Setup complexity	None — just put files in folder	Moderate — package install + Groups config
Best for	Small projects, prototypes, jam games	Any project targeting mobile or planning DLC

The Resources folder is not wrong for small projects. If you are making a game jam entry or a quick prototype with fifty assets, Addressables adds overhead you do not need. The switch makes sense when build size starts to matter, when you want scene-by-scene memory control, or when you are planning post-launch content updates.

Part 1: Installing the Addressables Package

1. In Unity, go to Window > Package Manager.
2. In the dropdown at the top left, select Unity Registry.
3. Search for Addressables.
4. Select Addressables from the results and click Install.

After installation, go to Window > Asset Management > Addressables > Groups. Unity prompts you to create the Addressables settings — click Create Addressables Settings. This generates a set of configuration assets in your project under Assets/AddressableAssetsData/. You do not need to edit these files directly — the Groups window is where all configuration happens.

The Groups window is the Addressables control panel. Every asset you mark as Addressable appears here, organized into groups. Groups control how assets are bundled for the build and where they are loaded from.

Part 2: Marking Assets as Addressable

Any asset in Unity — prefab, texture, audio clip, scene, ScriptableObject — can be made Addressable.

Method 1: Inspector Checkbox

1. Select any asset in the Project window.
2. In the Inspector, check the Addressable checkbox that now appears after the package is installed.
3. An address field appears below the checkbox, pre-filled with the asset's path. You can leave this as-is or replace it with a shorter, more meaningful address like "PlayerPrefab" or "Enemies/Goblin".

Method 2: Drag Into Groups Window

1. Open the Groups window (Window > Asset Management > Addressables > Groups).
2. Drag assets from the Project window directly into a group in the Groups window.

Both methods do the same thing. The Inspector checkbox is faster for individual assets. Drag-and-drop is better for marking many assets at once or for organizing assets into specific groups during initial setup.

Choosing Addresses

The address is a string you use in code to request the asset. The default (the asset's full project path) works but is fragile — if you move or rename the asset, the path changes and your code breaks. A custom address like "UI/HealthBar" or "Characters/Orc_Warrior" decouples the code from the file system location. Moving the asset later only requires updating the address in the Inspector, not in every script that references it.

Labels are another organizational tool. A label is a tag you apply to multiple assets — "Enemy", "Level1", "AudioMusic" — and you can load all assets with a specific label at once rather than loading each by individual address. Labels become useful when you want to load an entire category of assets, like all enemies for a specific chapter.

Part 3: Loading Addressable Assets in Code

This is where Addressables requires a different approach from Resources.Load. Addressables uses asynchronous loading — you request an asset and get back a handle that completes when the asset is ready. You cannot use the loaded asset on the line immediately after you request it the way you can with synchronous Resources.Load.

Loading a Prefab and Instantiating It

using UnityEngine;
using UnityEngine.AddressableAssets;
using UnityEngine.ResourceManagement.AsyncOperations;

public class EnemySpawner : MonoBehaviour
{
    [SerializeField] private string enemyAddress = "Characters/Orc_Warrior";

    private AsyncOperationHandle<GameObject> _handle;

    public void SpawnEnemy(Vector3 position)
    {
        Addressables.LoadAssetAsync<GameObject>(enemyAddress).Completed += OnEnemyLoaded;
    }

    private void OnEnemyLoaded(AsyncOperationHandle<GameObject> handle)
    {
        _handle = handle;

        if (handle.Status == AsyncOperationStatus.Succeeded)
        {
            Instantiate(handle.Result, transform.position, Quaternion.identity);
        }
        else
        {
            Debug.LogError($"Failed to load enemy: {enemyAddress}");
        }
    }

    private void OnDestroy()
    {
        if (_handle.IsValid())
            Addressables.Release(_handle);
    }
}

Three things worth understanding in this code before moving on.

.Completed += registers a callback that fires when the async operation finishes. You can alternatively use async/await with Addressables if you are comfortable with C# async patterns — either approach works, the callback version is shown here because it does not require additional setup.

handle.Status == AsyncOperationStatus.Succeeded is the error check. Addressables loads can fail — wrong address string, missing bundle, network error on remote assets. Always check the status before using the result.

Addressables.Release(_handle) in OnDestroy is not optional. Addressables counts references automatically and unloads assets when the count reaches zero — but only if you call Release. Forgetting Release is the most common Addressables memory leak. The asset stays in memory permanently until the application quits.

Instantiate and Release Together

For prefabs that you want to instantiate once and never reuse, there is a shortcut:

Addressables.InstantiateAsync(enemyAddress, position, Quaternion.identity).Completed += handle =>
{
    if (handle.Status == AsyncOperationStatus.Succeeded)
    {
        // The instance is already in the scene
        // Release is handled automatically when the GameObject is destroyed
        // IF you use Addressables.ReleaseInstance instead of Destroy
    }
};

When using InstantiateAsync, call Addressables.ReleaseInstance(gameObject) instead of Destroy to properly decrement the reference count. Calling regular Destroy on an Addressables-instantiated object destroys the GameObject but does not release the underlying asset from memory.

Part 4: Understanding Groups

Groups determine how Addressable assets are bundled together for the build. Getting Groups wrong does not break anything immediately — it degrades performance and build size over time in ways that are hard to diagnose later.

Default Local Group

The default group Unity creates is fine for getting started. Assets in this group are packed into the build and loaded from local storage. For a project that does not need remote content or DLC, one well-organized local group covers most needs.

One Asset Per Bundle vs Pack Together

In each group's settings, the Bundle Mode controls how assets within the group get packed:

• Pack Together — all assets in the group go into one bundle file. Loading any asset from the group loads the entire bundle into memory. Good for assets that are almost always used together (all assets for a specific level, all UI sprites).
• Pack Separately — each asset gets its own bundle. Fine-grained memory control, but more bundle files and more overhead per load request. Good for large assets you load infrequently.
• Pack Together by Label — assets sharing a label get bundled together. The most flexible option for projects with meaningful label organization.

The Pack Together trap: if you put all your game's assets in one group set to Pack Together, loading a single enemy prefab loads the entire bundle — potentially hundreds of assets — into memory at once. This defeats the purpose of Addressables. Organize groups by when assets are used, not by asset type.

Part 5: Building and Testing

Building Addressable Content

Before testing Addressables in a build, you need to build the Addressable content separately from the main Unity build:

1. Open the Groups window.
2. Click Build > New Build > Default Build Script.
3. Wait for the build to complete. Unity generates bundle files in your project's Library folder for local groups.

After building content, build the player as normal. The Addressables bundles are included automatically.

Testing in the Editor

In the Groups window, the Play Mode Script dropdown controls how Addressables behave in Play Mode:

• Use Asset Database (fastest) — loads assets directly from the project without going through bundles. Fastest iteration but does not test actual bundle loading behavior.
• Simulate Groups (advanced) — simulates bundle loading without building bundles. Slower than Asset Database but catches dependency and grouping issues without a full build.
• Use Existing Build (requires built groups) — tests exactly what will happen in a real build. Requires the Addressable content build to be up to date.

Use Asset Database during active development. Switch to Use Existing Build when testing a release candidate to confirm the actual bundle loading behavior matches what you expect.

Common Mistakes

• Forgetting Addressables.Release after loading. This is the source of most Addressables memory leaks. Every LoadAssetAsync call needs a corresponding Release when the asset is no longer needed. Store the handle and release it in OnDestroy or when the asset's lifetime ends.
• Using regular Destroy on Addressables-instantiated objects. Destroy removes the GameObject but does not release the asset from Addressables' reference count. Use Addressables.ReleaseInstance(gameObject) instead.
• Putting all assets in one Pack Together group. Loading any single asset from a Pack Together group loads the entire bundle. One massive group effectively re-creates the Resources folder problem — everything in memory, all at once.
• Not rebuilding Addressable content after changing assets. If you mark new assets as Addressable or change group settings after the last content build, the bundles are stale. Always rebuild content before testing with Use Existing Build play mode.
• Using the full asset path as the address and then moving the file. If the address is the file path and you reorganize your project folder, the address changes and any code referencing the old path breaks silently at runtime. Custom addresses decouple code from file location.
• Mixing Addressables and Resources.Load for the same asset. If an asset is marked as Addressable and also sits in a Resources folder, Unity may include it twice in the build — once in the Resources bundle and once in the Addressables bundle. Remove assets from Resources when you mark them as Addressable.

Action Steps

1. Install the Addressables package through Package Manager and create the initial settings file.
2. Identify three to five assets in your current project that are loaded at runtime — enemy prefabs, UI elements, audio clips — and mark them as Addressable with meaningful custom addresses.
3. Replace any Resources.Load calls for those assets with Addressables.LoadAssetAsync, add the Completed callback, and add Release in OnDestroy.
4. Organize those assets into groups based on when they are used — not by asset type.
5. Run a content build and test with Use Existing Build play mode to confirm loading works as expected.

Next Topics To Learn

• Unity Scene Management Explained — Addressables handles scene loading too. Addressables.LoadSceneAsync replaces SceneManager.LoadScene for scenes you want to load on demand from bundles.
• Unity Mobile Optimization Guide — build size reduction, memory management, and texture compression decisions connect directly to how Addressables groups are organized for mobile targets.
• Unity Save System Guide — ScriptableObject-based save data pairs well with Addressables when save state needs to reference assets by address rather than by direct reference.