Better Version Control for Design Projects

Make Git’s Large File Storage (LFS) work for your Framer files

As a designer, you’re already used to dealing with large files: a 100 MB Photoshop file here, a 30 MB Sketch file there… it quickly adds up. However, today’s large hard drives and cloud storage make “disk space” look like a problem of the eighties.

As soon as a modern version control system like Git enters your workflows, however, things suddenly seem to be worse. Version by version, your available disk space melts away like ice in the sunshine.
Framer users who work in teams will find this particularly frustrating, especially when it comes to collaboration on rich media prototypes.

But what about the songs they sing, about all the benefits that version control with Git is supposed to bring?

Fortunately, the songs are true: Git indeed brings countless advantages that a modern team cannot live without. But when large binary files (which are typical in a design project) are involved, plain Git simply isn’t enough. We need something on top that is specifically made to make handling large files easier.

Fortunately, there’s a Git extension answering to the wonderful name of “Large File Storage”!

First, the Problem

Before we dive into Git’s “Large File Storage” (in short: “LFS”), let’s take a closer look at the actual problem. Why is Git so bad with large files? And why is this a problem at all?

First, Git actually isn’t “bad” with large files. Rather, the nature of large files makes it very hard to handle them efficiently in a version control system.

Even the tiniest change (e.g. in a large Sketch file that you have imported into your Framer project) is still a change — and committing it to the repository means storing the whole, large file in its entirety again.

As a result, our local repository grows and grows — until it finally weighs multiple Gigabytes and becomes hard to use…

How Git LFS can Help

With this problem in mind, the clever folks at Atlassian and GitHub teamed up and set out to solve it. The result of their efforts is “Git LFS”, the “Large File Storage” extension.

Put simply, LFS reduces your local repository’s size by only providing the files you actually need. This means you only have those versions of your files on your hard drive that you’re actually working on.
Other, older versions are safely stored and available in a special LFS remote repository. Should you decide to turn back time and want to look at an older revision of your designs, LFS goes and downloads the corresponding files on demand.

To simply use Git LFS, we don’t need a deeper technical understanding of how exactly it works. Instead, let’s now install and set up LFS so we can get our hands on some examples.

Installation

Since LFS is not (yet) a core part of Git, it has to be installed as an extension — both on the server and on a user’s local machine.

Server

Most code hosting services like GitHub, GitLab, or Bitbucket already support LFS. If you’re not sure if yours is amongst them — or if you’re using a home-grown Git solution in your team — I suggest you check back with your administrator.

Local Computer

Whether you have to install LFS on your own computer, too, depends on how you’re using Git.

If you’re using Tower, a Git desktop client for Mac and Windows, you don’t have to install anything: Tower supports the Git Large File System out of the box.

If you’re using Git on the command line, you can download one of the binary packages for Mac, Windows or Linux. After you’ve executed the installer, you need to complete the process on the command line:

$ git lfs install

Tracking Your Files

Although installed, LFS will not perform its magic without further instructions. You have to explicitly tell it which files it should keep an eye on.

The ideal moment to do this is before these files are committed to the repository. Therefore, when creating a new Git repository, you should make it a habit to also set up Git LFS in that project. Otherwise, chances are that you forget and commit the files — and one day wonder why your local repository has become so big and bloated…

Let’s look at an example project that we’ve just started version control for. Especially in the “designs” folder we have a couple of heavyweights that we should better commit to the care of LFS:

Let’s tell Git LFS that it should manage that “app-icon.psd” Photoshop file. To do so, open your command line application and change into the root folder of your project:

$ cd ~/projects/design-inc/

Then, simply issue the `git lfs track` command, telling LFS which file exactly you want it to manage:

$ git lfs track “designs/app-icon.psd”

No fireworks went off. A bit disappointing, I know… But the command really has an effect: a new file named `.gitattributes` has been created. This is where Git LFS collects all the files and file patterns that we told it to observe. Let’s have a look at its contents:

$ cat .gitattributes 
designs/app-icon.psd filter=lfs diff=lfs merge=lfs -text

Wonderful! From now on, “app-icon.psd” will be managed by Git LFS.

Working with Other Git Commands

This is also a good time to break some good news to you: after installing LFS, using Git still works the same! You don’t need to change your workflow or learn many new commands. The things you already know about Git (and how to use it) still hold true.

For our example project, this means that we can now go ahead and add the changes we made to the repository. Notice that we should also commit the changes in `.gitattributes`, just like any other modification:

$ git add .gitattributes
$ git add designs/app-icon.psd
$ git commit -m “Add Photoshop icon file”

Tracking File Patterns

Telling Git LFS to track a single, specific file is all well and good — but it can quickly become tedious if you have many files in your project that you want to hand off to LFS. Luckily, there are other, more efficient ways to start tracking files.

One way is to track all files of a certain type. As an example, let’s tell LFS to watch all InDesign files:

$ git lfs track “*.indd”

If, on the other hand, you want LFS to track all contents in a certain folder, you can easily do that, too:

$ git lfs track “designs/*”

Just remember to always execute these commands from the root folder of your project.

Knowing Which Files are Tracked

From time to time, it might be good to check which files are actually and effectively tracked by LFS. That’s because simply typing our commands isn’t a guarantee that our commands were correct. If, for example, you entered a wrong file pattern (imagine typing “design/file.psd” instead of “designs/file.psd”…), LFS of course cannot know you meant a different file.

With the `git lfs ls-files` command, we can find out what’s really being tracked at the moment:

$ git lfs ls-files
6061a985b9 * designs/app-icon.psd

Note that this command will only return files that have already been committed to the repository. If you just added it to your project but haven’t yet committed it, it will not yet show up in this list.

Using LFS in a Desktop GUI

Working with Git on the command line is only one way to do version control. If the command line isn’t for you, I recommend you have a look at Tower, a Git desktop client for Mac and Windows.

Tower includes support for LFS out of the box, so you neither have to install anything nor remember any commands. By now, the app is trusted by over 80,000 developers and designers around the world.

Learning More

I hope this short tutorial gave you an overview of how LFS can improve your Git workflows — for example when committing your Framer prototypes with source files and other rich media, allowing your teammates to collaborate and iterate quickly.

If you want to learn more, both about LFS and Git in general, a lot of (free) learning material is already waiting for you.

Have fun using LFS in your projects!