Branching Strategies for Game Teams: Small vs. Large

Development Game Development DevOps git game-development architecture team-management

The branching strategy that serves a three-person indie team well will actively harm a thirty-person studio. Game development introduces constraints that most branching guides ignore entirely: binary assets that can't be merged, non-technical team members who need straightforward workflows, and repositories that routinely grow to hundreds of gigabytes.

Having worked on game teams ranging from small indie groups to larger studio setups, I've found that the right branching strategy depends almost entirely on team size and the ratio of binary to text content. This post presents the branching strategies I've seen work at four distinct team scales, along with the binary asset coordination workflows that make Git viable for game projects at each level.

Small Teams (2-5 Developers)

At this scale, coordination happens through conversation. The branching strategy should be as simple as possible.

main ─────────────────────────────────────→ (releases)
  │
  └── development ────────────────────────→ (integration)
        ├── feature/player-movement ──┘
        ├── feature/inventory-ui ─────┘
        └── feature/enemy-ai ─────────┘

Rules:

Why it works. Everyone on the team has direct visibility into what everyone else is working on. Conflicts are rare because the team is small enough to naturally avoid overlapping changes. The overhead of a more elaborate strategy isn't justified at this scale.

When to upgrade. When features begin conflicting regularly, or when the team brings on non-engineering disciplines (art, design, audio) who need their own integration space.

Medium Teams (6-15 Developers)

At this scale, distinct disciplines typically emerge. Engineers and artists, at minimum, are working in parallel and need separate integration spaces to avoid blocking one another.

main
  └── development
        ├── art ─────────────────────────→ (art integration)
        │     ├── feature/character-model
        │     ├── feature/environment-textures
        │     └── feature/ui-sprites
        │
        └── tech ────────────────────────→ (engineering integration)
              ├── feature/gameplay-movement
              ├── feature/combat-system
              └── feature/save-system

Rules:

Why it works. Artists and engineers stop blocking each other. A broken shader experiment in tech doesn't prevent the art team from committing new textures. Integration issues surface at the development merge, a controlled and scheduled event, rather than erupting unpredictably within individual feature branches.

The point. Separate integration branches by conflict domain, not by organizational chart. If two groups rarely modify the same files, they can and should work independently.

Large Teams (15-30 Developers)

At this scale, even individual disciplines need further subdivision:

main
  └── development
        ├── art/characters ───────────→ (character art)
        ├── art/environments ─────────→ (environment art)
        ├── art/vfx ──────────────────→ (visual effects)
        ├── tech/gameplay ────────────→ (gameplay engineering)
        ├── tech/ui ──────────────────→ (UI engineering)
        ├── tech/audio ───────────────→ (audio engineering)
        └── tech/tools ───────────────→ (tools/pipeline)

Rules:

Why it works. Sub-teams operate semi-independently. The character art team can iterate rapidly without worrying about environment art changes breaking their content. Integration happens on a controlled, predictable schedule rather than as an unpredictable interruption.

Very Large Teams (30+ Developers): The Hybrid Approach

Beyond thirty developers with heavy binary asset workloads, pure Git begins to strain under the weight. The practical answer at this scale is often a hybrid architecture:

┌─────────────────────┐     ┌──────────────────────┐
│   Perforce (P4V)    │     │     Git (GitHub)      │
│                     │     │                       │
│  Binary Assets      │────→│  Source Code          │
│  - Textures         │     │  - C++ / Blueprints   │
│  - Models           │     │  - Build scripts      │
│  - Audio            │     │  - Configuration      │
│  - Animations       │     │  - Documentation      │
│                     │     │                       │
│  Native locking     │     │  Branching & merging  │
│  Efficient binary   │     │  Code review (PRs)    │
│  handling           │     │  CI/CD integration    │
└─────────────────────┘     └──────────────────────┘

When to go hybrid:

When to stay pure Git:

Binary Asset Coordination

Regardless of team size, binary assets require explicit coordination because they can't be text-merged. The following workflow applies universally.

The Locking Protocol

Developer A:
  1. git lfs locks                              # Check what's locked
  2. git lfs lock Content/Characters/Hero.uasset # Claim the file
  3. [Edit in Unreal Engine]
  4. git add && git commit && git push
  5. git lfs unlock Content/Characters/Hero.uasset
  6. [Slack notification: "Hero.uasset unlocked"]

Developer B (wants same file):
  1. git lfs locks                              # Sees Hero.uasset is locked
  2. [Coordinates with Developer A or works on something else]

Reducing Lock Contention

The way to manage binary locking is to need it less often:

  1. Decompose assets. One Blueprint per actor, not one monolithic Blueprint per system.
  2. Use sub-levels. Split world content across multiple level files so environment artists aren't competing for the same file.
  3. Split data tables. Organize them by category rather than consolidating into a single large table.
  4. Keep Blueprints thin. Implement business logic in C++, which is mergeable. Reserve Blueprints for visual wiring and configuration, which requires locking.

Performance Tips for Large Repositories

Artists working with large repositories benefit substantially from shallow clones and selective LFS pulls:

# Shallow clone, and skip the LFS smudge filter so the checkout
# downloads no binary content at all
GIT_LFS_SKIP_SMUDGE=1 git clone --depth=1 https://github.com/studio/game.git

# Now pull only the LFS files you actually need
git lfs pull --include="Content/Characters/*"

# Prune old LFS files to reclaim disk space
git lfs prune

The environment variable is what stops the download, and it is the part most guides leave out. Git LFS installs a smudge filter that runs during checkout, so a plain git clone downloads every LFS object the checked-out commit references before any selective pull gets a chance to run. --depth=1 on its own only excludes historical versions of those objects, which on a project whose weight is mostly in the current checkout is the smaller half of the saving.

This distinction matters most during onboarding. A full clone of a 200GB Unreal project can take hours. A clone that skips the smudge filter, followed by a selective pull, takes minutes, getting a new team member productive on the same day they join.

Matching Strategy to Team Size

Team Size Strategy Key Feature
2-5 Simple feature branches Minimal overhead
6-15 Discipline branches (art/tech) Isolation by conflict domain
15-30 Sub-team branches + automation Scheduled integration + forward-merge
30+ Hybrid Git + Perforce Right tool for each file type

The guiding principle I follow is this: add complexity only when simpler approaches break down. Start with the simplest strategy that could plausibly work for the team. Upgrade when the team feels the pain, not before. Every layer of branching overhead is a layer that every developer has to understand and follow correctly.

References