Use the right tool for the job: Git LFS with Artifactory

In a recent conversation I had with a developer that works with my wife, who works as the QA Manager for an awesome educational games company, she shared with me a very painful issue that most game developers (probably) share: storing binary assets in Git. This is an issue for everyone in this industry – regardless of your choice of VCS.

Well, not just game developers really, but anyone with 3D models, images, sounds, videos, and anything which is not text-based that has to be in your version control system (think animation studios, graphical engine manufacturers, websites, etc,).

Admittedly, with a little creative thinking you can make Git or any other VCS Ok, as was elegantly explained by Atlassian’s Nicola Paolucc. Using tools like git-media, git-fat, git-bigstore and git-annex you can even make it kind of  manageable. Each of these tools has it’s own method of achieving the end goal with their strengths and weaknesses to consider.

The thing is, Git is a source control system for a reason. It is exceptionally good in managing sources. But for binaries?

Source control systems are bad for your binaries.

Why, you ask? Here’s a small list:

• First and foremost – a VCS is not a repository! It can’t calculate indexes on the server and it doesn’t support any dynamic REST API, such as the dependency resolution APIs.
• Versioning mismatch. Source files are versioned by their content. VCSs know how to differentiate them and understand what changed. Binaries, on the other side, are usually versioned by their name. From the VCS point of view, they are different entries, each one without any version history.
• Source control knows how to search sources. And, of course, the most important type of search is by content. However, searching for binaries is different: what matters most is the file metadata, the location, structure of the file name and, in case of archived artifact, the contents of the archive.

Another tool for assets? Please, no!

But using one server for all my assets, both sources and binaries is very convenient – one might say.
Once we learned how to use Git correctly (and it wasn’t easy!) it makes sense to use it for all the files that we need from server.

Good news! The newest addition to these tools is Git LFS by GitHub which makes an effort at tackling the problem (binaries in VCS repo, remember?) by separating the blobs themselves and your Git repository (indeed, similar to the other tools, yet more enterprise-grade).

Git LFS stores only a text pointer in the repo while managing where the blobs are stored and when to upload download them for you.

BUT where do these blobs go? GitHub will offer 1GB of free storage and it’s support is still in early-access; to date, there are no other production-grade services out there that offer support for the Git LFS API.

Enter Artifactory

Managing your binaries has always been our specialty at JFrog, so why not leave it to the pros?

Artifactory 3.9 brings full support for Git LFS in the form of a local repository that holds all of the blobs the Git LFS client manages, with all of the powerful features that Artifactory offers out-of-the-box like AQL, user plugins, user management, replication and of course the powerful REST API.

There’s no storage quota on your organization’s Artifactory servers, no bandwidth limit, no file size limit (albeit the inherent issue Git has with crunching extremely large files), even no downtime.

And most importantly – All of your binaries are managed in one place that you already have an established concrete workflow for – not distributed across multiple hard-to-track online services.

Visit our Knowledge Base and learn how to setup Git LFS to work with Artifactory in 5 minutes.