I've just used git-tfs to checkout a TFS repo into a Git repo. The .git directory comes to 2.33GiB, and the primary reason for this is a couple of large directories coming to about 650MiB each. Each directory is chock full of (roughly 1500) JPEG image files that range from 50KiB to 5MiB in size.

This obviously makes the Git repo uncomfortably large, and yet the images do kind of logically fit into the solution as they are converted to smaller sized images and served out to the client. A few of them would be OK, but the sheer number of them takes the repo to being too large. Neither Github nor Bitbucket will even allow you to push a Git repository larger than 2GB (Github don't explicitly state this but I tried to push it and it failed). What would be the best way to handle this? This question on this same site has top answers suggesting that it's basically OK to check images into source control.

  • GitHub does document the quota sizes for repositories. Although it doesn't say that you can't push 2GB, it does say that any repository over 1GB will get attention and that no files can be over 100MB. However, GitHub also does recommend that "versioned assets, such as graphics" and "large configuration files" be stored in version control. Are these images something that your application needs to look and feel properly or are they data that your application works with?
    – Thomas Owens
    Commented Sep 7, 2015 at 12:57
  • I'd say they're used as part of the application's user interface (it's mostly not my project; I've just taken it over and surprise surprise I've extracted it from a classic TFS repo via git-tfs).
    – Jez
    Commented Sep 7, 2015 at 13:26
  • Have you looked into git-lfs.github.com or similar stuff like git-fat, git-annex, etc?
    – kat0r
    Commented Sep 7, 2015 at 13:45
  • @kat0r Yes, and none of them are great, considering they don't actually check the file into Git and require all users to be using a particular plugin for it to work.
    – Jez
    Commented Sep 8, 2015 at 16:13

3 Answers 3


If these images are not going to change often then I think you can store them in an artifact repository like Nexus. Using it you have some version control because you can have different versions of the same artifact, it is well integrated with build tools (like Maven) and it handles binary files better than git. On the other hand you lose something like a 'git log' for your images and a single direct relation (version) between your source code (on Git) and these images (on Nexus).


If it's data that the application works with and not resources that the application needs to be usable, then I would consider totally removing them from the repository entirely.

I'm not sure what your application is, but consider a music player. You may have images to represent various UI controls - buttons, icons, your application logo, and so on. However, you may also be displaying album artwork. You would need to distribute buttons and icons with your application so that other developers have them and they are included when users install the application, but you don't need to include music files or album artwork in your releases - your users will need to provide these. However, you may want to capture some as test cases. You should manage these files and control them, but they don't need to be in the same repository as your source code.


I was always a big fan of blob fields. So I would store them in a database. You also have the advantage of storing image metadata (if you have such a need) with the image . I have tried this approach with both Mssql Server and Oracle and both have lived up to the task. With mysql I couldnt say.

  • 2
    How does this answer the question? It's about storing images in a Git repository, not about a relational database. Commented Sep 6, 2015 at 19:51
  • @toniedzwiedz If you interpret the question as an X-Y problem, then suggesting solutions outside of the question box may make sense. Commented Sep 6, 2015 at 19:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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