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?
\$\begingroup\$
\$\endgroup\$
2
-
\$\begingroup\$ Related: gamedev.stackexchange.com/questions/35949/… \$\endgroup\$– HouseCommented Mar 24, 2013 at 15:28
-
1\$\begingroup\$ Source code is everything you can't generate from source code. Assets, textures, art, and documentation is also source code under that definition. \$\endgroup\$– Christoffer HammarströmCommented Mar 24, 2013 at 21:01
Add a comment
|
3 Answers
\$\begingroup\$
\$\endgroup\$
0
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.
\$\begingroup\$
\$\endgroup\$
3
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.
answered Mar 24, 2013 at 19:40
-
\$\begingroup\$ good point, but you can clone without fetching all the history stackoverflow.com/questions/11497457/… \$\endgroup\$– AliCommented Jul 9, 2016 at 21:09
-
1\$\begingroup\$ @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. \$\endgroup\$ Commented Jul 10, 2016 at 18:16
-
\$\begingroup\$
\$\endgroup\$
0
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.
