Every project needs a version control system

Introduction

The version control system is like a granular backup of every file in the project. The server keeps all versions of all files ever submitted by users. Older versions of files can be easily accessed and compared to other versions. Programmers typically compare two versions of the source code to understand what has been changed.

Any asset can be reverted to an older version. You can easily discard your local version of the file and download the latest version from the server. This way you can recover your files and project after any kind of disaster.

Version control allows developing projects on a few separate branches on streams.

There are few systems to choose from. You can use either by subscribing to the appropriate cloud service (cost depends on team size, used storage and transfer) or installing the server on your own machine.

How it actually works

There are some functions that every system has, regardless of special features. Although some actions have different names in different systems.

• Update/Sync. The most common action of downloading the current state of the project from the repository - this is how we call the project stored on the version control server.

  Usually, it doesn't happen automatically (like cloud sync solutions, i.e. Dropbox). Every user decides when to perform a sync. Otherwise, we wouldn't know on which version of the project we work exactly.

• Submit/Push. Sending your local changes to the server where everyone can view it and download it.

• Revert/Discard. You can simply discard changes done to any local file. Doing that syncs given file to the latest file version on the server.

• Lock. This will lock a file to only you, so nobody else could send this file to the server. This prevents conflicts when many people would submit different versions of the same file. Your version wouldn't include changes done by other persons, so their work would be lost.

  Locking only affects binary assets which cannot be easily merged.

• Merging. Text-based assets (like source code) can be merged even if multiple developers would send changes to the text file without communicating with each other. Merge tools (offered by every version control system) allows us to resolve conflicts, merge changes from all versions of the given file.

• Branches/Streams. Merging text files allows programmers to work on many branches - separated versions of entire projects. Typically there's at least one "release" branch, the stable version of the project released to customers. And one or many development branches, where developers submit their changes every day, so new bugs can appear every minute.

Choosing a system

Unreal Engine supports 4 version control systems. We describe every system for you, so you can make an informed decision on which system you gonna use.

• Keep in mind, you could use different systems for different needs, i.e. using Perforce for your internal projects, but Git to grab projects from GitHub (Unreal Engine source code would be a prime example).

• Forcing yourself and the team to use a single solution for everything might be a bad choice.

Perforce

Perforce (P4) is a standard choice for every big studio. Also for every small studio founded by people who already worked with, they don't even look at other solutions (even if they use Git for different things).

• P4V client is designed around support for binary assets (most of the content in every game project) and ease of use for non-programmers (most of the team members).

• It's a system designed to handle the enormous amount of binary data, for repositories where the single version of data is counted in terabytes.

• The entire repository (all version of all assets your team ever submitted) can take only a few terabytes for AAA games (hundreds of thousands of commits or more).

• Support for file locking it's here since forever - this is a crucial feature, prevents other people from editing binary assets when you edit it.

• The free license can be used up to "5 users and 20 workspaces". However, it's confusing what that's mean, technically every person could use a single workspace.

• Details of paid licenses are even less clear as there's no information on the official page. The word of mouth says the perpetual license costs a few hundreds of dollars per user. There are no monthly subscripton plans.

• Perforce uses a centralized server, the client connects to the server every time the file status is about to change. The advantage is that P4V client doesn't download gigabytes of meta-data to your machine, just your assets.

• You can easily configure which asset types use "exclusive checkout" (file locked while you edit it) or "writeable" (no file locking, typical for source code and binaries). You could even set server to keep only the last version of the asset.

Learn more about why Perforce could be the best choice for you in the long run: Perforce vs Unreal. This page also debunks myth "Perforce is only free up to 5 developers".

Git

Git is the most beloved system of programmers. Definitely the first choice for a person who uses it for versioning the source code, especially if already contributed to open source hubs like GitHub.

• Nothing beats Git when it comes to supporting multiple code branches, super-easy merging changes between branches and much more code-related operations.

• The thing is Git wasn't initially designed for binary assets. However, in recent years it got support for Large File Storage (support for efficient versioning of binary assets) and file locking. It's not enabled by default, but it's easy to turn it on. This makes Git gamedev-friendly.

• Git is a free and open source distributed version control system. It's everywhere, difficult to find programmer who didn't use it already. And that's the reason why they would want to use Git for gamedev project without evaluating anything else.

• Git system doesn't enforce you to use specific clients. The most popular ones are Source Tree, GitHub Desktop, Tortoise Git.

• This is system is truly distributed, which means it doesn't need a constant connection to the central server.

  • It creates special .git folder in your local copy of the project. This allows easy and fast switching between branches locally. You can easily create temp local branches, play with the entire codebase.

  • When you submit a change, first it sends changed asset to this folder. And then you need a second step submitting a change to the actual server.

• Keep in mind, Git clients aren't that friendly for non-programmers as competitors.

  • If you're surprised by this statement, please check Perforce vs Unreal describing useful features of P4 client in daily gamedev work. There are reasons why studios using P4 keep using it.

• And it's awesome support for branching can be useless for your project.

  • Small gamedev project often use only a single branch (merging binary assets it's a hell), with rare branches for making demo.

  • Although games updated every single week after release can use branching extensively. Remember that working on multiple branches would still be limited by the Unreal itself (using tons of blueprints which are difficult to merge). You might need to develop a game in certain way to fully utilize branching with any VCS.

  • Branches are obviously useful while working on a large codebase with many programmers, i.e. your own engine. Still, Epic uses Perforce internally. Git is used to publishing the engine's source to everyone for free.

Learn more: Git vs Unreal

SVN

It's probably the simplest system to start with. It has been a popular middle ground between P4 and Git for years.

• It's free to use.

• System supports file locking.

• The most popular client app would be Tortoise SVN, similar to Tortoise Git.

• Its popularity decreases because of recent Git upgrades (LFS, file locking).

Learn more: SVN vs Unreal

Plastic

It's a new kid in gamedev.

• It attempts to offer advantages of Git and Perforce in a single system.

• There's a free plan, but the essential features are available only if paying the subscription fee.

Learn more: Plastic vs Unreal