Documentation

Support

Unity Version Control

DevOps

On-prem

Gluon

Editor plug-in

Open Unity Dashboard

Unity Version Control

Workflows and partial replicas

Learn about different workflows and ways to manage large repositories with Unity Version Control.
Read time 2 minutesLast updated 21 days ago

Centralized workflow

Unlike distributed systems that require a full local clone of the repository, Unity Version Control (UVCS) allows you to connect a local workspace directly to the central server. This workflow has the following advantages:
  • You can check out only the files you need.
  • You send commits directly to the central server.
  • You don't need a local copy of the repository, and can save disk space.
This workflow can be helpful for artists or other team members that don’t require the full version history.

Distributed workflow

If you prefer a distributed workflow with a local repository, Unity Version Control (UVCS) provides features to manage repository size. For example, you can use nodata replicas, or xlinks.

Nodata replicas

To manage repository size in a distributed workflow, you can create a nodata replica of the repository. A 
nodata
replica is a clone that contains all the repository's metadata but none of its actual file data (blobs):
  • Metadata includes all changesets, branches, labels, and permissions.
  • Data refers to the actual content of the files (blobs).
This setup results in a very small local repository. When you access a file, the data is retrieved on-demand from the server. You can browse history, diff files, and change branches without locally stored file data. Any new checkins you create add data to your local repository. You can then push the checkins to the central server. For more information on how to create and manage nodata replicas, refer to Use a nodata replica.

Hydrating replicas for offline work

A nodata replica needs a connection to the central server to fetch file data. With the 
hydrate
command, you can selectively download data for offline use. Hydrating is the process that occurs when you download the actual file data from the original server and store it in your local nodata replica. A common workflow is to create a nodata replica of the main branch and hydrate only the latest changeset. This workflow provides a complete working copy for development without downloading the data for the entire project history. For more information on how to hydrate a nodata replica, refer to Hydrate a replica for offline use.

Use Xlinks to structure projects

UVCS supports Xlinks, which allow you to split a large project into several smaller, more manageable repositories. For example, you can fully replicate the code repository with data for main development, while using a nodata replica for a large art asset repository. Alternatively, you can use an Xlink that points directly to a centralized art repository to avoid needing a local clone of the repository entirely.