Version control systems (VCS) allow teams to back up and archive the source code of their projects. This makes it easier to review and make edits to the repository or restore previous versions in the event of a build-breaking error.

Version control is the systematic process of tracking and managing updates to source code and assets. Version control systems are foundational for efficient workflows, acting as the single source of truth for programmers, artists, and other team members while allowing everyone to contribute to a shared codebase independently. They also act as a safety net, making it possible to “undo” code updates if a catastrophic error is introduced during development.

Factors like a team’s size and geographic distribution can influence which version control systems a game developer might choose to implement. Individual developers may find that a local solution is all they need to stay on track, while larger teams should look for a more robust and scalable version control system that helps them collaborate across time zones and geographies.

Version control also supports the ability to create branches. A branch is a single copy of code managed within a VCS. By creating branches, developers and other team members can work independently of one another within separate streams. Version control helps developers work collaboratively and in sync in a shared codebase.

Version control systems are a central pillar of DevOps, allowing teams to collaborate and rapidly iterate on a project’s source code.

Working with version control means always having a backup. Individual project updates are gathered periodically into a singular group, known as a “commit,” before being merged into the main source code. A version control software is essential for tracking every modification to each project file. If a mistake or regression is made, users can return to an earlier version of that file almost instantly. Version control also provides a log of all changes, who made the changes, and every iteration of each change. With a version control system in place, all stakeholders and team members can work seamlessly on many files simultaneously. Version control systems allow you to merge all the code edits and changes into one centralized repository.

With access to a full project history and the ability to undo mistakes, version control systems simplify bug tracking and make it easier to restore previously removed features.

Creating a new repository in your version control system opens up the main branch: This is called the main branch or trunk master. The trunk master is where the main code base enters the pipeline, where it’s then compiled and deployed to the end user.

So what are branches? Branching is the process of forking out code from the master branch. This allows developers to make their own personal changes to the code without committing it to the main. Using branches means developers don’t need to have complete file history on a single server; instead, they can maintain a full history of changes made to their code over time. The version control system can then take these separate branches and merge them back into the main branch. If a developer isn't ready to merge their task branches into the main, they can commit their changes to a separate branch and merge it to the main branch at their leisure.

A proper branching strategy is crucial to avoid code conflicts and broken builds. Luckily, good version control systems allow teams to easily sync with the main branch and fix any potential code conflicts – even after code has been committed to the main integration branch.

Distributed version control systems let you check in, branch, and merge without connecting to the main server. Each contributor works from a cloned repository stored in the cloud. Their main advantage is that teammates can work separately, at speed, without worrying about slow networks or VPNs. It’s even possible to work on a project offline, but an internet connection is still required to push or pull updates

Distributed version control systems can come with long wait times if you ever need to download your entire project history, particularly in large projects with extensive change histories. Studios working with large binary files should carefully monitor storage use, since these files can take up space quickly.

Studios looking for flexibility and the potential to increase productivity should consider distributed version control.

Centralized version control systems use a check-in/push workflow to connect to the main server. Any changes or updates to the source code are automatically stored in the repository as a new version. Centralized version control systems feature powerful branching and merging capabilities that don’t require the repository to be cloned to multiple machines. In that sense, it’s potentially more secure.

Centralized version control systems require a network connection. Because teams are tied to a single version of the project stored on one server, service interruptions can cause major slowdowns. Another disadvantage of centralized version control is that it can scale poorly. The more developers you have contributing to your project, the fewer opportunities there are to push changes in a stable environment, which can lead to issues like merge conflicts.

If you’re interested in version control systems that are easy to set up and use, you may consider a centralized workflow.

Local version control systems are the simplest form of version control, and they are used primarily by solo developers rather than teams. With local version control, all project data is stored on a single computer, and changes made to project files are stored as patches. Each patch only contains the updates implemented since the previous patch. If a problem occurs with a specific version of your project, you must examine the entire collection of patches to piece together what the project files looked like at a specific moment in time to diagnose the issue.

Because they’re tied to one computer, local version control systems are inherently less flexible than their distributed and centralized counterparts. Collaboration between teammates is challenging, and if the database is compromised, it can be difficult if not impossible to restore the information you’ve lost.

Generally, it’s fine to start out with local version control, but as soon as you start to scale up (even from a one- to a two-person team), it’s better to start working distributed or centralized.