Summary

A branch is an independent line of development. In game development, branches let you work on a new feature — an enemy AI, a new level, a combat mechanic — without touching the stable version of your project. If the feature works, you merge it in. If it breaks things, you discard it. Because Git branches are extremely lightweight (just a pointer to a commit), creating and switching branches is instant and has no performance cost.


Key ideas

What a branch actually is

When you make commits, Git builds a chain of snapshots. A branch is simply a named pointer that tracks the most recent commit on that line of work. The special pointer HEAD always points to the branch you are currently on — it tells Git “this is where my next commit should go”.

main ──────────────────────────────► commit-C ← HEAD

When you create a new branch from main and make commits on it, the history diverges:

main  ─────────────────────────────► commit-C
                                           ↓
feature-enemy-ai  ────────────────► commit-D → commit-E ← HEAD

Creating and switching branches

git branch feature-enemy-ai        # create a branch (stay on current branch)
git checkout feature-enemy-ai      # switch to it

Or create and switch in one step:

git checkout -b feature-enemy-ai   # classic syntax
git switch -c feature-enemy-ai     # modern syntax (Git 2.23+)

Unity works fine while you switch branches. Git updates the files in your working tree to match the branch you switch to. Unity will detect the changes and reload.

Listing and deleting branches

git branch                      # list all local branches (* = current)
git branch --merged             # branches already merged into current (safe to delete)
git branch --no-merged          # branches with unmerged work
git branch -d feature-enemy-ai  # delete (safe — refuses if unmerged work remains)
git branch -D feature-enemy-ai  # force delete (even if unmerged)

Merging

When a feature is ready, merge it back into main:

git checkout main               # switch to the branch you are merging INTO
git merge feature-enemy-ai      # merge the feature branch in

Fast-forward merge

If main has not moved since the branch was created, Git can simply move the main pointer forward to the tip of the feature branch. No new commit is created.

Before:
main ────────────────────────► commit-C
feature ─────────────────────► commit-C → commit-D → commit-E

After fast-forward:
main ────────────────────────────────────────────────► commit-E

Git will report: Fast-forward.

Three-way merge

If both main and the feature branch have new commits since they diverged, Git performs a three-way merge: it compares both branch tips against their common ancestor and creates a new merge commit combining both lines.

git merge feature-combat
# Git creates a new merge commit automatically
# You will be prompted to write a commit message

Resolving merge conflicts

A merge conflict happens when both branches changed the same lines of the same file in different ways. Git cannot automatically decide which version is correct — it needs you to choose.

What a conflict looks like in a file

<<<<<<< HEAD
float moveSpeed = 5f;
=======
float moveSpeed = 8f;
>>>>>>> feature-movement-overhaul
  • <<<<<<< HEAD — the version from your current branch (the one you merged into)
  • ======= — separator
  • >>>>>>> feature-movement-overhaul — the version from the incoming branch

Resolving the conflict

  1. Open the conflicted file in your editor
  2. Choose which version to keep (or write a combined version)
  3. Delete all the conflict markers (<<<<<<<, =======, >>>>>>>)
  4. Save the file
  5. Stage the resolved file and commit:
git add PlayerMovement.cs
git commit -m "Merge feature-movement-overhaul: use 8f move speed"

Example resolution

// Chose the feature branch value after discussion with team:
float moveSpeed = 8f;

Tips for avoiding conflicts:

  • Communicate with teammates before editing the same scripts
  • Keep each feature branch focused — smaller branches conflict less
  • Pull from main frequently when working on long-running features

Typical feature branch workflow

This is the standard workflow for Unity game teams:

# 1. Make sure main is up to date
git checkout main
git pull
 
# 2. Create a branch for the new feature
git checkout -b feature-inventory-system
 
# 3. Work on the feature — commit as you go
git add Assets/Scripts/Inventory/
git commit -m "Add item pickup and storage logic"
git commit -m "Add inventory UI panel with slots"
 
# 4. When ready, merge back to main
git checkout main
git pull                              # get any new team changes first
git merge feature-inventory-system
 
# 5. Push to GitHub
git push origin main
 
# 6. Delete the feature branch (optional but tidy)
git branch -d feature-inventory-system

Unity-specific notes

Scene files and merge conflicts: Unity .unity scene files are partially binary and can be difficult to merge manually. Best practices to reduce scene conflicts:

  • Work on different scenes in different branches where possible
  • Use Unity’s YAML text serialisation (enabled by default) — it at least makes scene conflicts readable
  • Coordinate with teammates before making large scene changes — “I’m editing Level3 scene today”

Prefabs: Similar to scenes, prefab conflicts can be complex. Assign ownership of specific prefabs to specific team members during a sprint.

Meta files: Every asset in Unity has a .meta file storing the GUID. These must be tracked alongside the asset — never add *.meta to .gitignore. If meta files conflict, the version with the correct GUID for your project should be kept.