Branching in software development is taught in terms of code. Feature branches, release branches, hotfix branches — the mental model is a programmer committing text files. Game development breaks that model in at least three ways.
First, your contributors have wildly different technical backgrounds. A senior C++ programmer and a concept artist using Photoshop are both committing to the same repository. The branching strategy has to work for both of them, or it will not work for either.
Second, many of your assets cannot be merged. You can have two programmers work on the same file and resolve their conflict with a text diff. You cannot do that with a binary FBX or a Unity scene. Your branching model has to account for non-mergeable files, which means it has to minimize situations where two people modify the same asset simultaneously.
Third, games ship to milestones, not to continuous deployment. The branching model needs to map to how the team actually organizes work — by sprint, by feature, by milestone — not just by "feature branches merge to main."
What Does Not Work
Pure trunk-based development
Trunk-based development — everyone commits directly to main, no long-lived branches — works well for small software teams with high test coverage. For a game studio, it is a fast path to broken builds. Artists committing work-in-progress assets directly to main means the build breaks whenever an asset is half-finished. You need some form of isolation.
Gitflow for game assets
Gitflow (main, develop, feature/*, release/*, hotfix/*) is popular in software teams. It does not translate well to game development. The model assumes everything can be merged — but binary assets cannot. It also assumes your team has a uniform technical level around Git commands. In practice, a six-branch model with strict conventions will be ignored by anyone not already comfortable at the terminal.
What Does Work
Milestone branches with a stable main
Keep main always buildable. All active development happens on a milestone branch — one branch per sprint or per major deliverable. When milestone work is complete and tested, it merges to main. This limits the blast radius when something breaks: it breaks on the milestone branch, not in the shared stable build.
Milestone branches are coarse enough that most artists and designers can understand the model: "we're on the alpha-sprint branch, everything goes here." They do not need to know anything about feature branching to follow this rule.
Feature branches only for code
For programmers making changes that need review or could destabilize other systems, feature branches make sense. Use them for engine modifications, new systems, and anything that touches shared interfaces. But do not require artists and designers to work in feature branches — the overhead is not worth it for asset work.
Asset branches for big, parallel art work
When multiple artists are working on different parts of the same level simultaneously, give each one a short-lived asset branch. The key discipline: asset branches should be short — a few days at most. The longer an asset branch lives, the harder it is to integrate. Set a rule: if your branch is more than three days old, you must integrate before creating more work on it.
File locking for non-mergeable assets
This is not optional. Before anyone starts editing a scene file, a Blueprint, or any other non-mergeable asset, they should lock it. The lock tells everyone else: do not touch this. When the work is committed, the lock is released.
Locking requires that your version control system supports it natively, and that the lock status is visible inside the engine editor. A locking system that requires a command-line step will not be used consistently by non-technical team members. The lock needs to show up as a visual indicator when someone opens a file in Unreal or Unity.
Integrating Artists Into the Flow
The hardest part is not designing the branching model — it is getting non-technical team members to follow it without friction. A few things that help:
- In-editor integration. If your version control lives inside the engine, artists see branches and locking status as part of their normal workflow. They do not need to open a terminal or a separate application.
- Clear naming conventions. Branches named after milestones ("sprint-14", "alpha-build") are easier to understand than branches named after tasks or ticket numbers.
- Short-lived branches by default. Every branch has an expected end date. If it does not merge within that window, someone needs to explain why. Long-lived branches accumulate debt that makes integration painful.
- One person owns integration. Designate a lead or a technical director who is responsible for merging asset branches to the milestone branch on a regular cadence. Do not make integration everyone's problem — make it someone's specific job.
The Bottom Line
There is no single branching strategy that works for every studio. But the common thread in strategies that work is simplicity at the contributor level. Your artists and designers do not need to understand Git internals. They need to know: what branch am I on, do I need to lock this file, and where does my work go when it's done.
If your branching model requires more than that to explain, it is going to fall apart under the pressure of a production schedule.