Of course, LFS cannot simply "magic away" all that large data: it accrues with every change and has to be saved. Very quickly, the repository will weigh tons of megabytes and soon gigabytes - which makes cloning and managing it very tedious.Īlthough I only talked about "design" files, this is really a problem with all "large" files: However, here's the catch: each time our designer makes a change (no matter how small) to this new Photoshop file, she will commit another 100 MB to the repository. It makes a lot of sense to put your design assets under version control, too. However, until now, we haven't included our design assets (Photoshop, Sketch, etc.). Nothing special: some HTML, CSS, and JS files and a couple of small image assets. Let's consider a simple website project as an example: Without LFS: Bloated repositoriesīefore we look at how exactly LFS works its wonders, we'll take a closer look at the actual problem. Luckily, there's a Git extension that makes working with large files a lot more efficient: say hello to " Large File Storage" (or simply "LFS" if you prefer nicknames).
The general benefits of version control still apply and should be reaped in all kinds of projects.
This quickly adds up and makes your repository almost unusable due to its enormous size.īut of course, not using version control for your design / concept / movie / audio / executables / work cannot be the solution. Working with large binary files in Git can indeed be tricky.Įvery time a tiny change in a 100 MB Photoshop file is committed, your repository grows by another 100 MB. It happens with the best of intentions: your design team adds their large graphic files to your project repository - and you see it grow and grow until it's a multi-gigabyte clump…
0 kommentar(er)
