Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How do I handle images in a Git repo?

Tags:

git

github

I have inherited a medium sized iOS project - ~30,000 lines of code - that has an insane number of image assets. Of course we use Git/Github to scm. Currently the images are included in the directory tree and thus gets ingested into the repo, bloating the heck out of it and generally making development a big headache.

We have 4 devs on the project, some virtual. It occurs to me to move the images to Dropbox, refer to them from the iOS project and keep things ship shape.

Does anyone have a comment on this idea? What do you do do deal with image/video/audio files in a Git scm setup?

like image 512
dugla Avatar asked Apr 22 '11 14:04

dugla


People also ask

Can Git handle images?

You can store the image and binaries using Subversion system (SVN). The images and other binaries are not going to change very often, but still you can get notified when those files are changed or updated centrally. Git is best for version-ing only source code and only include source codes in Github.

Should images be in git?

There is no absolute response but I advise you to keep your images in the repository with the other files. Consider your git repository as your versionned website, images included. It will ease you if you want to automate your deployments. It will keep your website history consistent too.


2 Answers

I'd be pretty nervous about that, actually; what if you want to update an image, then change your mind? Or what if you need to build a maintenance release with old images?

If this is really a problem -- and I've never seen this actually be a problem in practice, but I'll take your word for it -- why not just use one repo for the images, another for everything else? You can then just be lazy about syncing the image one.

like image 138
Ernest Friedman-Hill Avatar answered Sep 27 '22 18:09

Ernest Friedman-Hill


It can be a bit of a pain to deal with, but what I've used in the past are submodules for images and media. That way, you can pull down just your code without getting the images if you want to, but you can still keep your images and media in sync with your code. When the submodule history would get too big, we could just create a new repo without the history, and swap out the old submodule for the new one. That way, people could be in sync with the latest version of the media, without having to pull the full history.

We would frequently start out with green screens of our video in the submodule, so we could develop with the video before it was in its final form, but once it was composited, we would break the submodule history and push out a new submodule that had just the composited videos. That avoided having an entire extra copy of every video, while still allowing you (with a little manual work of swapping the submodules around) to get the old version out if you needed to.

Submodules will increase the amount of work that you will need to do. If you want to commit changes to your images, you need to change them in the submodule, commit that, push it, then go to the parent project, commit the change to the submodule, and push that. For simple cases you can write some scripts to make this a little easier, but in more complicated cases like merge conflicts it will be considerably more complicated than using a single project for everything.

like image 44
Brian Campbell Avatar answered Sep 27 '22 19:09

Brian Campbell