Every game team hits the same wall: Git slows to a crawl, clone times balloon to 20+ minutes, and someone accidentally commits a 400 MB FBX that's now baked into history forever. Standard Git was designed for text — binary game assets need a different strategy.
Why Git Fails with 3D Assets
Git stores every version of every file in its object database. For plain text, this is brilliant — diffs are tiny. For binary files like `.fbx`, `.glb`, `.png`, or `.psd`, every changed version is stored in full. A 50 MB character mesh revised ten times consumes 500 MB in `.git/objects` before a single team member clones the repo.
The compounding problem: unlike code, binary files don't benefit from delta compression. Git's pack algorithm can't diff a binary — it stores the whole blob each time. Repositories routinely balloon past 10 GB when texture sets and mesh iterations pile up, and `git clone` becomes a team-wide productivity killer.
Common failure modes:
- `git push` timeouts on meshes over ~100 MB
- `git clone` taking 30–45 minutes on a fresh machine
- CI pipelines failing because the runner runs out of disk space mid-clone
- Merge conflicts on binary files that produce corrupt, unusable assets
Setting Up Git LFS for a Game Asset Repository
Git Large File Storage (LFS) replaces large binary blobs with lightweight text pointers inside Git, while the actual file contents are stored on a separate LFS server. Your repository stays lean; the heavy files live elsewhere and are only downloaded when you actually check out a branch that needs them.
Installation is one package plus one command: `brew install git-lfs` on macOS, `sudo apt install git-lfs` on Ubuntu/Debian, or `scoop install git-lfs` on Windows — then run `git lfs install` once to activate it for your user.
From there, tracking is driven entirely by your `.gitattributes` file. You can add rules one at a time with `git lfs track "*.fbx"`, but for a game project it's better to commit a complete baseline up front:
```
# 3D mesh formats
*.fbx filter=lfs diff=lfs merge=lfs -text
*.glb filter=lfs diff=lfs merge=lfs -text
*.blend filter=lfs diff=lfs merge=lfs -text
# Textures (same pattern for .tga, .exr, .hdr, .tiff)
*.png filter=lfs diff=lfs merge=lfs -text
*.psd filter=lfs diff=lfs merge=lfs -text
# Audio and compiled engine assets
*.wav filter=lfs diff=lfs merge=lfs -text
*.uasset filter=lfs diff=lfs merge=lfs -text
*.umap filter=lfs diff=lfs merge=lfs -text
*.unitypackage filter=lfs diff=lfs merge=lfs -text
```
Extend the same one-line pattern to every binary format your pipeline touches (`.gltf`, `.obj`, `.ma`, `.mb`, `.jpg`, `.ogg`, and so on). The `-text` flag prevents Git from applying line-ending normalization to binary files — critical for avoiding corruption on Windows. Commit the file with `git add .gitattributes` and every tracked type routes through LFS on the next push.
To confirm a file actually landed in LFS, run `git lfs ls-files` — each entry shows a short hash followed by `*` when the content is stored in LFS, or `-` when only the pointer exists and the content hasn't been uploaded yet.
Partial Clone and Sparse Checkout for Large Teams
Once your LFS is configured, you can go further with partial clones and sparse checkout — essential when a 100-person studio has a repository with 200 GB of assets but most team members only work on one area.
```bash
# Clone without downloading LFS content, then fetch only what you need
GIT_LFS_SKIP_SMUDGE=1 git clone https://github.com/yourorg/game-assets.git
cd game-assets
git lfs pull --include="Assets/Characters/**"
# Or, with Git 2.25+: sparse checkout of a subtree
git clone --filter=blob:none --sparse https://github.com/yourorg/game-assets.git
git sparse-checkout set Assets/Characters Assets/UI
```
A character artist only pulls character assets. A UI designer only pulls UI textures. CI pipelines for a specific game module only download what they need to build it.
| Approach | Clone Size | Fetch Time | Best For |
|---|---|---|---|
| Full clone | Full repo | Slow | Small teams, all-hands devs |
| `GIT_LFS_SKIP_SMUDGE` | Repo only | Fast | Read-only browsing |
| Partial clone + LFS pull | Subset | Fast | Large studios, area-specific work |
| Sparse checkout | Subset tree | Very fast | Monorepo setups |
LFS Locking: Prevent Binary Merge Conflicts
Binary files can't be merged. If two artists modify the same `.blend` file on separate branches, there's no way to automatically combine their changes — you get a corrupt file or one set of changes is silently discarded.
Git LFS file locking solves this by enforcing exclusive editing. Mark conflict-prone formats as `lockable` in `.gitattributes` (append the flag to the existing line, e.g. `*.blend filter=lfs diff=lfs merge=lfs -text lockable`), then:
```bash
git lfs lock Assets/Characters/hero_mesh.blend # claim before editing
git lfs locks # see who holds what
# Assets/Characters/hero_mesh.blend alice ID:42
# Assets/Environments/cave.blend bob ID:43
git lfs unlock Assets/Characters/hero_mesh.blend # release when done
```
Artists see immediately who has a file checked out, preventing wasted hours working on an asset someone else already has locked. This is the closest you get to Perforce-style exclusive checkout without abandoning Git entirely.
Migrating an Existing Repository to LFS
If you're adding LFS to a repo that already has bloated history, `git lfs migrate` rewrites it in place. Run `git lfs migrate info --top=10` first to see which extensions are eating the most space, then move the offenders into LFS with `git lfs migrate import --include="*.fbx,*.glb,*.png,*.psd" --everything`, and finally publish the rewritten history with `git push --force-with-lease`.
Warning: this rewrites commits, so all team members will need to re-clone. Coordinate the migration during a low-activity window and communicate clearly before running it.
Hosting Options: GitHub, GitLab, and Self-Hosted
All major Git hosts support LFS, but bandwidth and storage quotas vary significantly:
| Host | Free LFS Storage | Free Bandwidth | Paid Tiers |
|---|---|---|---|
| GitHub | 1 GB | 1 GB/month | Data packs from $5 |
| GitLab.com | 5 GB | 10 GB/month | Scales with plan |
| Gitea (self-hosted) | Unlimited | Unlimited | Server costs only |
| Forgejo (self-hosted) | Unlimited | Unlimited | Server costs only |
For studios with large asset budgets (50+ GB), self-hosting Gitea or running an S3-backed LFS server (via `git-lfs-s3` or Minio) is often more cost-effective than paying per-GB bandwidth on GitHub. A $20/month VPS with 500 GB storage handles most indie studio workloads.
Summary
Git LFS transforms a painful binary-file problem into a manageable workflow. The core steps: install LFS, track your asset types in `.gitattributes`, use file locking for exclusive edits, and adopt partial clones for large teams. The upfront setup takes less than an hour; the payoff is a repository that stays fast as your asset library scales to thousands of files.
For teams starting fresh, integrate LFS on day one — migrating history later is possible but disruptive. For existing repos over a few GB, schedule a `git lfs migrate` session and get clean before the problem compounds further. If your assets come from BitSoul's marketplace, they're already organized with clean naming conventions that slot directly into this pipeline.