How to Use Git and Version Control for Game Projects

Game projects often fail at version control before the first commit. The reason is rarely the branching strategy or the platform. It is that nobody configured the repository for game files in the first place.

A Unity or Unreal project is not a software codebase. It carries textures, audio, meshes, and compiled assets alongside scripts, and each of those file types needs different handling from day one. This guide works through that setup in the order it actually matters: assets first, workflow second.

Why standard Git breaks on game projects

Git stores every version of every file it tracks. For text files like scripts and shaders, that is efficient because Git only records what changed. For binary files like .psd textures or .fbx models, it stores the entire file again with every commit. A repository that naively tracks game assets will grow to an unmanageable size within weeks.

Git LFS solves this by replacing large binary files with small pointer files inside the repository. The actual binaries live on a separate LFS server. The working directory still sees full files. Git just tracks lightweight references instead of full content.

Setting up Git LFS for Unity and Unreal projects

Install Git LFS once per machine before touching any project files:

git lfs install

Then define which file types get offloaded in a .gitattributes file at the repository root. For a Git LFS Unity setup, track these formats as a starting point:

• *.png, *.jpg, *.psd, *.tga for textures and image assets
• *.fbx, *.obj, *.blend for 3D models and animations
• *.wav, *.mp3, *.ogg, *.aiff for audio
• *.mp4, *.mov for video
• *.dll, *.unitypackage for compiled assets and packages

Unreal projects extend that list with .uasset, .uplugin, .umap, and .ushaderbytecode. Each entry in .gitattributes follows this syntax:

*.uasset filter=lfs diff=lfs merge=lfs -text

*.fbx filter=lfs diff=lfs merge=lfs -text

Commit the .gitattributes file before adding any engine content. Retrofitting LFS into a repository that already holds binary history is far more complicated than configuring it at the start. GitHub's free LFS tier provides 10 GB of storage and 10 GB of bandwidth per month for Free and Pro accounts, with Team and Enterprise plans getting 250 GB of each. Game projects can blow through bandwidth quickly because every clone and CI checkout pulls the full LFS files, so factor storage and bandwidth costs into platform decisions early.

The .gitignore files every game developer needs

The second configuration that should exist before any engine content enters the repository is a .gitignore that excludes everything auto-generated.

For Unity projects, the critical exclusions are:

• Library/ rebuilds on every fresh import and can reach several gigabytes. Committing it even once requires rewriting the repository history to undo it.
• Temp/ is deleted and recreated constantly during editor sessions with no meaningful state between them.
• Obj/ holds intermediate compilation files that regenerate on every build.
• Build/ stores player build outputs that belong in a deployment pipeline, not a repository.
• Logs/ collects diagnostic logs with no role in version history.
• UserSettings/ stores per-machine editor preferences that override teammates' local configurations when committed.
• .vs/ and .idea/ are IDE workspace folders that differ across every machine.
• *.sln and *.csproj are auto-regenerated by Unity on every script change, producing constant, meaningless conflicts between different Unity versions.

For Unreal projects, exclude:

• Binaries/ stores compiled engine and game code that regenerates on every build.
• Intermediate/ holds temporary files from shader compilation and code generation. One of the largest auto-generated folders in any Unreal project.
• Saved/ collects autosaves, crash reports, and local config backups. All machine-specific.
• DerivedDataCache/ is Unreal's processed asset cache that rebuilds automatically and can grow larger than the source assets themselves.
• *.pdb are debug symbol files generated during compilation. Large, machine-specific, and irrelevant to collaborators.
• ShaderCompileWorker/ contains shader artifacts that vary across hardware configurations, which produces conflicts if committed.

One Unity-specific setting worth verifying for version control for games: in Project Settings, confirm Editor > Asset Serialization Mode is set to Force Text. This is the default for new Unity projects in recent versions, but older projects or those migrated from Mixed mode may still serialize as binary. Force Text saves scenes and prefab files as human-readable YAML, which makes Git diffs meaningful and enables UnityYAMLMerge during conflicts.

Branching strategies for solo developers and small teams

Branching strategy should match team size, not convention.

Solo developers and tightly coordinated pairs work best with trunk-based development: all changes land on main, sometimes through short-lived branches, with frequent commits to keep history granular enough to reverse individual decisions.

Teams of two to eight developers working on separate systems simultaneously need feature branches. One developer opens a branch, works until complete, then merges back to main through a pull request. Recommended naming conventions:

• feature/ for new systems and mechanics.
• fix/ for bug corrections.
• art/ for asset-only changes.
• audio/ for sound and music work.

Projects approaching a milestone should cut a release/v1.0 branch. Post-release fixes merge to both the main and the release branch, keeping a patchable stable version without freezing active development.

Handling merge conflicts in game files

Script conflicts are resolved in the standard way: Git marks diverging sections, the developer edits to the correct final state, removes the markers, and commits.

For Unity scenes and prefab files serialized as YAML, configure UnityYAMLMerge as a custom merge driver for:

• *.unity scene files
• *.prefab prefab files
• *.asset scriptable objects and settings

Unreal Blueprints are binary, which means they cannot be auto-merged the way text files can. Unreal does ship a built-in Blueprint Merge Tool that opens a 3-way view of the local, remote, and base versions, but it functions more as a viewer than a true merge — you copy nodes between versions manually rather than getting an automatic resolution. The more practical answer for most teams is to git lfs lock before editing any blueprint, blocking simultaneous edits at the repository level. Beyond tooling, the most reliable conflict prevention comes from:

• Assigning file ownership so one developer controls a given scene or blueprint at a time
• Using modular prefab composition, so developers work on their own prefabs rather than the same scene file
• Committing small and often to reduce the window during which divergence accumulates

When to consider Perforce over Git

For Perforce Unreal workflows at scale, the centralized model offers advantages that Git with LFS cannot fully replicate:

• Developers check out specific files from a depot rather than cloning a full repository, so workstations stay lean regardless of total depot size.
• File locking is native to the model and prevents simultaneous edits on binary assets with no ambiguity about the current version.
• Perforce integrates directly into the Unreal editor for in-engine asset sync and check-in.
• The P4V graphical client is more accessible to artists and non-programmers than Git tooling.

For teams larger than 10 to 15 people with asset libraries heading past 50 GB, Perforce is worth evaluating against Git with LFS. Perforce P4, formerly Helix Core, is free for up to 5 users and 20 workspaces, so it is testable before any commitment. Perforce Software

For indie studios and solo developers, Git with LFS running on GitHub, GitLab, or Azure DevOps covers every practical need at no cost. The setup overhead of Perforce rarely pays off below that scale threshold. Above it, most large studios use Perforce because the file sizes, team coordination needs, and cost of binary conflicts outpace what Git with LFS can absorb.