Does it make sense to use source control to manage graphics files (e.g. PSDs & AI files)

Question

Of course source control tools like Git, (Mercurial, SVN, etc...) can do a great job at managing source code. But I wonder, do these tools provide the developer with any advantage when used to store copies of files such as PhotoShop PSDs and Illustrator AI files? Does it make sense to use these tools with these kind of files? Would I be storing less in the repository than the sum of the file sizes of all of these files? Even though the file format of these files is only machine readable, I would expect that in for such applications, especially when dealing with vector rather than raster graphics, a small part of these files would change, and much of the rest would remain the same.

Thank you for your insight.

Assignor

I have to disagree with some of the opinions expressed in the answers given with respect as to whether or not the images should be managed by the SCM system. Any file that is required by your project should be in source control. Otherwise, how can you recreate a version for client support or rollback? @Alex touches upon a solution: using an extra layer of data that points to the image repositories. This would need to be automated so that the integrity of and the correlation between the SCM and image repositories stays intact. – Impressionist

Note: considering PSD can now (June 2014) be diff'ed graphically, it can make sense managing it in a Git repo: see my answer below – Ellsworth

Answer 1

Although this is very opinionated issue, I would say no — at least for git.

• Git was not created as a storage solution.
• There's no way to merge image files.
• Therefore, branches don't make sense — if the only way to merge these branches together is to choose which version is correct, you're better of replacing the file right away.
• Git GUI tools are inferior to console, and are not simple. Do you want to teach your art team what the difference between commit and push is?
• When you checkout git repo, you checkout the whole history of all files, starting from initial commit. If you work on binary files long enough, the size will get enormous.
• Many git hosting sites, such as github, have limits on individual file sizes.

I think that you're much better off with dropbox.

Destalinization

Yeah, you're right. Git is not really suitable for graphics. It's best to simply store various versions of the graphics files on disk and upload at least some of them to DropBox or store them somewhere safe and make backup copies. The files are quite large, and tend to vary completely from one edit to another. – Assignor

"When you checkout git repo, you checkout the whole history of all files, starting from initial commit. If you work on binary files long enough, the size will get enormous." - Not necessarily true. When doing a git checkout, add the --depth <depth> option to only clone a shallow version. – Tetrode

you are right that branching/merging doesn't make much sense, and file sizes are an issue * GUI tools are actually easier to use that CLI tools * dropbox is a bad suggestion, unless that's the only way to share large files with other people – Corrinacorrine

> "Git was not created as a storage solution" The OP doesn't ask for storage but for version management. It seems there is currently nothing better (except a few specific proprietary progiciels), so text VCS are the only option so far and if not perfect, still much better than cloud storage to manage vectors or rasters versions within a team. You loose advantages of diffing (depending on the frontend though), merging and stuff, but you take the rest, which is already very good compared to collaborating with a cloud storage service (a total hell for medium to large organizations). – Gatecrasher

Answer 2

Git itself can manage any kind of data, provided their are not too big or to numerous.
See "git with large files" ("large" as in size or number).

Diff'ing pictures/graphics isn't a feature supported by Git natively, but a Git repo hosting service can extends its web GUI to offer such a support.

GitHub just announced (June 2014) "ePSD Viewing & Diffing", which extends their " image viewing and diffing" (Nov. 2011)

Any PSD assets in your repositories will be treated just like images, meaning you can view them inline and use our three image view modes to see what's changed in a commit.

Update Mach 2022: this is no longer supported.
See "Working with non-code files" for the files for which diff is supported.

Ellsworth

Answer 3

Those answering "no" have very good reasons, but it isn't impossible.

I'm successfully using GitHub to manage an open source project consisting of hundreds of Illustrator files and PDFs (and also some code and text, but that's a tiny blip in comparison). The repo comes out at about 8GB. The reason I'm doing something so insane is because the Illustrator files are the core of the product, not merely decorative artwork to go along with it - they are the source of the project - and because I wanted to make sure it would stay open source.

There have been some sticking points, and things to be aware of. I would suggest:

• Don't try this unless you're pretty familiar with git. Resolving conflicts and branching issues can get really thorny, and you may have to do some pretty arcane stuff to keep the repo happy. Nobody expects you to know every corner of git (I'm not sure a sane person could), but know enough that you can google the rest.

• Make sure you're comfortable using git on the command line. GUI tools may shield you from complexity, but they also prevent you from fully understanding what's going on under the covers. Once you have that understanding, you're free to use a GUI for 95% of the time.

• Avoid branching if possible. Binary files don't merge the way code does, so bringing branches together can get messy and laborious.

• Learn about specific features of git that can help you to manage the size and complexity of the repo: partial checkouts, tags, git gc, etc

• Take time to plan in advance. It may be that you would benefit from separating the project into two or more git repos, or from combining it with another service.

• If you're using a hosting service, make sure you know what limits they impose on the repo. For example, GitHub will complain about files over 100MB. Here are their recommended guidelines for binaries.

Nomothetic

Update years later: I moved the project to git LFS, which is available on GitHub for a price. LFS works better for large binary files than ordinary git. – Nomothetic

Answer 4

No, I would not recommend using git, svn, etc. for version tracking. A surprising amount of lines will change between barely altered versions of Adobe files - see for yourself by doing a diff comparison. This is especially true when options like native file compression are turned on in Illustrator.

By judiciously using layers, links, and saving milestone versions of files, you'll have a much more efficient use of storage than SVN's could ever give you for native Adobe files.

The one exception I can think of is for XML based files, like pure-vector SVGs.

Colossae

Yes, perhaps files created with other graphics programs such as Inkscape (which uses SVG) don't come across the same problem and can thus be source controlled without the overhead PSD or AI files would have. – Assignor

Answer 5

If you just need simple version management with a simple UI, Subversion works pretty well for managing these files. It has good GUI support (e.g. SmartSVN or TortoiseSVN) with shell integration. It's also much easier to selectively check out only the files you need.

Promiscuity

Fair enough. In my opinion though Git is a more modern SCM system, and does a better job in general. – Assignor

Answer 6

For all of you pointing that the size of the files is a big problem, Git-LFS comes to solve that problem.

It is easy to install and use, and popular platforms such as GitHub, GitLab or Bitbucket support it without any problem.

Peccary