Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Is it usual to manage not only source code, but all assets, textures, art, documentation files, etc under git repository for version controlling? For example I wanna to get back old version of texture. If it is very bad practice what tools do you use for version control of assets and other stuff?

share|improve this question
Related:… – Byte56 Mar 24 '13 at 15:28
Source code is everything you can't generate from source code. Assets, textures, art, and documentation is also source code under that definition. – Christoffer Hammarström Mar 24 '13 at 21:01
up vote 10 down vote accepted

I would say that's a very good practice. Source control should be used for source and assets. You can think of it like a backup, you want to be able to restore from source control everything needed to build your game.

I linked a question that's about storing assets in a repository. There are some repositories that work better than others for storing art. They'll allow you to "diff" the art and see what's changed. Others will just treat the assets as binary data, so you'll have to check it out to see what's different. This also means you'll have to upload the entire asset when it changes, as it won't be possible for the repository to "know" (parse) what has changed between versions.

I store everything in the repository. When I got my new laptop, I was able to check out my repository and build my game, without the need to copy any assets from anywhere else. That means I also store the 3rd party libraries, assets and source control in my repository.

share|improve this answer
Thank you for explanation! – Edward83 Mar 24 '13 at 16:58

Git is not great for non-text files. Cloning a git repo requires downloading all historical versions of a file, unless using a big file extension (non-standard, often not supported by GUIs) or special commands (requires being a git guru to do). The same goes for most DVCS systems. For a texture, model, or audio clip, this means pulling many copies of a very large file. 1GB of assets can easily be 200GB of historical revision data, and git makes you download it all when you clone a new repo, and download all intermediate revisions when grabbing the latest. This becomes a huge bottleneck down the road when you can least tolerate production delays.

Subversion, Perforce, and so on are better choices for assets, as they only require downloading the desired revision (the latest, usually). You can use them only for assets and use git for code, or also use them for source too. Perforce has some features that let it act like a very clunky DVCS, and is better than SVN functionality (though much more conplex) in my experience, however cost means you'll likely use Subversion.

Most content professionals have little need for DVCS, and some have trouble with even the basics of classic VCS anyway. Don't saddle the with git. Or Mercurial, DARCS, etc.

share|improve this answer
Thank you for the good advice!!! – Edward83 Mar 24 '13 at 19:44
good point, but you can clone without fetching all the history… – Ali Jul 9 at 21:09
@Ali: shallow clones do not at all solve the problem adequately (they disable many commands, aren't the default for most GUIs, etc.) and are essentially useless for most things besides CI servers and the like. Newer git solutions like git-lfs have arisen to address the problems I outlined in an attempt to get content-heavy teams onto git. – Sean Middleditch Jul 10 at 18:16

It's good practice, even as an artist when you are working on a project there tends to be some form of version control, file corruption or bugs do happen, without source control artists tend to do revision saves anyways which is just a huge mess.

Real world example you can see of this is the open movies projects made with Blender (Big Buck Bunny, Durian, etc)

Art pipeline for a game is more or less the same, except there might be a build step for the assets themselves to do some conversion from big fat data to engine specific format, such as texture compression and model format conversion.

Some tools, like GitHub even offer nice image comparison tools and alike, which is a lot better than comparing a binary blob.

Since an assets repository can be absolutely huge, my/our preference is to keep a seperate assets repository which is a submodule in the project repository. You don't want to pull down gigabytes of assets when all you want is to branch the source for instance.

share|improve this answer
Casper thank you! – Edward83 Mar 24 '13 at 18:35

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.