Part 3 | Branching

May 15

Arvid Burström, Technical Animation Director and Patrik Åkerberg, Tech lead Tools & CI

Installments

In part 2, our developer learned how to preserve the past. Every Change was tracked. Every version of the Game could be restored. Now they face a different problem.

The Game is live and needs to stay stable. But at the same time, the developer wants to work on something risky, a new system, or experimental tech that might take weeks and will almost certainly break things along the way.

They need two things at once:

Maintain a safe, stable version of the Game, Main.
Manage a sandbox where breaking things is allowed, Test.

Let's Introduce some new concepts.

Branch – An isolated History of Changes.
Main Branch – The primary, stable version of the Game.
Test Branch – A branch used for experiments or focused work.
Branching – The act of creating the Branch.
Merging – The act of bringing changes from one branch to another
Squashing – The act of clumping a series of Changes into one, making merging easier

Creating a Branch

When a developer creates a new Branch, they do it by taking a snapshot of an existing one and giving it a name, the new one has the exact same Files, same History, same working Game. At creation they are identical, but from this point on the Branches will start to diverge.

The Dev Branches Main to create a safe test environment for working on new horse mechanics for their game. Now any change made to the Branch Horse2.0 is isolated from wrecking Main.

On Main, the developer continues normal work, fixing bugs and maintaining the Game. On the Horse2.0 Branch, they can roam freely.

Both Branches evolve independently, side by side, the Dev can easily switch between them at will, choosing which version of the Game they want to work on.

Eventually, the experiment succeeds (hopefully). The new Horse mechanics are much better than what exists on Main.

It's time to Merge!

Merging

A Merge takes the Changes introduced on one Branch and applies them to another. We want Horse2.0 back to Main and ship it to the hands of our players!

There are many ways to merge but we’ll use the simplest case, Squashing. This means we’ll take a series of individual Commits from a Branch, combine them into one package and send it back to Main.

*The 1, 2, 3 Commits on Horse2.0 become a single Commit on main by Squashing and Merging.*

After the merge:
Main now has a single Commit called “New Horse”, it’s ready to get sent to our players! Horse2.0 still lives with the full History (you can delete the branch post merge but you don’t have to) if we ever want to keep working on it or go back in time.

But now here comes the true magic of Branches:

While we were experimenting on the Horse branch, we were able to safely deploy multiple bugfixes on Main without risk of breaking anything for our playerbase! (Or accidentally leaking some new mechanic not yet ready for public eyes.)

Summary

With Branching:

Multiple versions of the Game can exist in the same Repository
Risky and stable work can happen in parallel.
Once a Branch has served its purpose it can be merged back to Main.

Ok!

Our developer now has Version Control to go back in time, Branching to explore alternatives.
We can maintain a stable game while being able to take risks.

So far so good for our dev team of… ONE developer.

But wait…

I’m good at coding but not at content (or vice versa). I need more people!

What happens when the team grows?
When artists, designers, and engineers all need to work at the same time?
When one developer’s Changes affect another developer’s tools?
Someone is working on the wrong branch!