← Back to home

Binaries inside git

On the whole, it's not a bad practice, and it's easy to correct or extend when it becomes an issue.

This post has been archived.

There are all sorts of things people say about what you should and shouldn’t store in Git. When it comes to advice about storing binaries, I think most conventional advice is misguided.

It’s okay to check binaries into Git.

It takes a couple of megabytes, and on the whole doesn’t take that much space, even if you’re updating them regularly. A clone will take a long time (maybe a minute instead of a couple seconds), but that’s not the end of the world since it’s just a clone.

Where you run in to trouble is when the binaries are large (> 25Mb), and frequently rotating. This can mean a long-clone.

You can also always use Git LFS when it becomes an issue. In fact, this is how some companies I’ve talked to get their binaries into production. Production instances get read-only access to a special LFS git repository. It’s simple, it works, it’s extensible.

Critics of this say that Git isn’t for binary files, and that it’s a misuse of the system. I think that’s fair, but doesn’t matter in most cases. You can misuse any system or tool as long as you understand the limitations of your misuse. Misuse the tool until you find the breaking point, and then build what you were missing from there.

Go ahead. Put your (some of) binaries inside Git.

git | code
2021-02-28