Why Git is Not Good for Games.

This is a post that I’ve been meaning to write for a while, mainly so that I can refer to it when someone can’t understand why I use SVN.

So Git. Its the Golden Hammer of version control. Its really good for making Twitter so its great for games, right? It seems people are taught in college its the best version control system. So why use anything else? But not all VCS is equal. Game studios generally do not use Git or distributed VCS (some do tho!). Here is why I think this is true, and also this Quora question has a few points.

So why is Git (and DVCS) not good for games?

The Programmer-Centric Fallacy

The first reason is that programmers frequently think that only programmers make games. Guess what? LOTS of different types of people make games. And their technical skill is at varying levels. As a person who has worked on multi-disciplinary teams in games, teaching any version control system requires work. I’ve seen non-technical users struggle with Git. Do I want to add hurdles to teams working together? Or just pick a solution that’s more inclusive and doesn’t have ‘deep shit’?

The Merging Fallacy

(Merging is actually the hard part of branching, hence why I’m referring to it instead of branching)

Linus was scp-ing tarballs to kernel.org for years while Git was a twinkle in his eye. Merging is great in Git, sure. Do I merge enough to care? Not really. If I dealt with merging enough to care I would use Perforce not SVN (and I would assume the project would be big enough to warrant the budget for it).

The Data Problem


Games have lots of binary assets. I’ve worked on games with tens of gigs of data. This simply doesn’t work well with Git. Some people have said the answer to this is Git-LFS. And yes, that’s an answer. Its an answer to a problem created by Git. I’ve seen some studios use Git for code and SVN for assets. But at some point you have to ask yourself: if you’ve got to implement a separate solution for binary assets, maybe you’re using the wrong version control system?

I’ve seen some people say that you shouldn’t be committing assets to version control. These comments really highlight the Programmer-Centric Fallacy but really hones in on exactly what makes games different than other software: assets and code are one. Version control is not just for code. Code is not just code. Code is tightly coupled to data in games, and that’s not a bug.

The Distributed Problem

People are people. And people make mistakes and that’s ok. And people will do things like commit 300MB zip files to version control (and of course all the files in the zip next to it). And everyone can download that zip forever and ever in Git because its forever in the history. Thanks Git!

Git users like to say that having the entire repository locally is a great feature. And sure, its great that you can commit immediately and its fast. I shaved a few seconds off a commit, so what? When I’m downloading someone’s mega-zip of stock image textures I’m twiddling my thumbs anyway.

Sure I can chant some incantations to remove files from git. Or I can remotely delete the problem on the server and move on. Wasting a few hundred megs is cheaper than the time it takes to deal with the problem.

Don’t Git Me Wrong

Its not all doom and gloom. I *like* Git. I use it. I’ve made games with it. And game studios use it. But what would make Git (or DVCS) be an appropriate choice?

  • Your game is small. And you know it will never be big.
  • Your art assets are minimal. Pixel art, procedural assets, or a text adventure.
  • Its just you. Do what you want. 🙂
  • Your team knows Git. And team being developers/artists/designers.

When is it not an appropriate choice?

  • You’ve got a lot of assets (which is pretty likely!).
  • You have non-technical users who need access to the project.

Lastly this is all contentious and highly opinionated! As I said I am writing this to have something to reference the next time someone is surprised to find that I’m still using SVN. And I also hope that this pushes people to more critically evaluate their use of git before starting a project.

I am interested in others’ opinions on this. Am I alone in this? I don’t think so. Head on over to Reddit and let me know.


Whew, lots of opinions on Reddit! Shocker. Some people have said that I shouldn’t just ‘git bash’ (which I’m not!) and talk a bit more about the differences between git and alternatives.

When you use a distributed system, the expectation is that you have the entire repo for that module. If you have a 50GB repository then this means you have a 50GB checkout on your hard drive. If you are using something like SVN/Perforce you just have the current checkout. If the current version of what you’re working on is 5GB then that’s what you pull down. Do I need everything? Probably not! Maybe even never! But I can grab it all if I want.

A number of comments talk about how either I shouldn’t put my binary assets in Git or that I should just put my assets into git-lfs/dropbox/google drive or something. I tried to be clear but to re-iterate: versioning your assets separately than your code is a terrible idea. Just don’t do it. Using an add-on like git-lfs is a solution, possibly a good solution even! But its a solution to a problem created by git in the first place!


Can’t reply to all the redditors who say I hate git or am using git wrong. Its really interesting to see how ingrained the idea is that you only put source files in version control. Why is this arbitrary line drawn in the sand between the art and code? I think of games as the synergy between these two things.

To all the people who are saying git works great and they don’t have any issues: again, awesome. Keep using it! If git-lfs works, use it! Keep making awesome games whatever the tech!


I wanted to archive this conversation regarding Tim Sweeney trying to figure out what to do with 10TB of the Unreal Engine. The conversation is quite interesting (click to read the rather long thread), and apparently Git+LFS is not all its cracked up to be?