Handling Large Binary Files with LFS

Large binary files are a tough problem for version control systems — including Git. The reason is that Git is optimized for text files: when a text file changes, delta compression produces a tiny diff because only a few bytes changed. Binary files (images, PSD files, videos, audio, compiled artifacts) compress much less efficiently — a small semantic edit (like saving a PSD) rewrites bytes throughout the file, resulting in a delta almost as large as the full file:

Text file change:    → tiny delta     (a few bytes)
Binary file change:  → near-full copy (still ~50 MB)

After 10 edits to a 50 MB PSD file, your repository holds ~500 MB of binary data — even if each edit was a minor tweak.

Git LFS (Large File Storage) solves this by replacing large binary files with a tiny pointer in your repository, while the actual file content is stored separately in a dedicated LFS store:

Git repository           LFS store (remote)
┌───────────────┐        ┌──────────────────────────────┐
│ pointer (1 KB)│ ─────▶ │  design.psd v1  (50 MB)      │
└───────────────┘        │  design.psd v2  (50 MB)      │
                         │  design.psd v3  (50 MB)      │
                         └──────────────────────────────┘

Your Git repository stays small. At checkout time, LFS fetches only the version you actually need.

Tracking Files with LFS

After installing LFS on your local computer once, you'll be able to "track" files (or file patterns) via LFS.

As a result, these files will not be stored in your local repository, but in a dedicated LFS cache (locally) and store (remotely). In the end, you'll have smaller local Git repositories because LFS manages data storage very efficiently - saving only the data you need on your local computer.

To tell LFS to handle a certain file, use the "track" command:

$ git lfs track "assets/design.psd"

Of course, you can also have LFS manage all files of a certain type:

$ git lfs track "*.psd"

Pattern Reference

What to track	Command
A specific file	git lfs track "assets/design.psd"
All files of a type	git lfs track "*.psd"
Multiple types at once	git lfs track "*.psd" "*.ai" "*.sketch"
All files in a folder	git lfs track "assets/**"

Always quote your patterns — without quotes, your shell expands wildcards before Git LFS sees them, creating individual file entries instead of a reusable pattern.

To list all currently tracked patterns, run git lfs track with no arguments. To stop tracking a pattern:

$ git lfs untrack "*.psd"

The .gitattributes File

After executing the "track" command, you'll notice that a file named ".gitattributes" (located in the root of your repository) was changed. This is because LFS notes the files and file patterns you want to track in exactly this ".gitattributes" file.

Each tracked pattern appears in .gitattributes as a single line — for example:

*.psd filter=lfs diff=lfs merge=lfs -text

• filter=lfs — LFS handles converting the file to/from a pointer on commit and checkout
• diff=lfs — LFS handles diffs
• merge=lfs — LFS handles merges
• -text — disables line-ending conversion (binary content must not be modified)

You can edit .gitattributes manually instead of using git lfs track — the result is identical.

Just like with the ".gitignore" file that you might already know (and if you do, you'll like this tool), you should keep in mind that changes in ".gitattributes" should be staged and committed to the repository like any other change, too.

Where Does Git LFS Store Your Files?

Git LFS uses a two-tier storage model:

Your machine                    Remote server
┌──────────────────────┐       ┌──────────────────────────────┐
│ .git/lfs/objects/    │ ◀───▶ │  LFS store (GitHub, GitLab,  │
│ (local cache)        │       │  Bitbucket, or self-hosted)  │
└──────────────────────┘       └──────────────────────────────┘

• On git add: LFS caches the file locally and writes a tiny pointer into Git.
• On git push: cached LFS objects are uploaded to the remote store.
• On git checkout: LFS checks your local cache first, downloading from the remote only if needed.

To free up local disk space by removing cached versions you no longer need:

$ git lfs prune

Limitations to Keep in Mind

Git LFS is the right tool for large individual binary files (images, video, compiled binaries). A few things to consider before adopting it:

• LFS must be installed on every developer's machine before they can work with the actual file content. Cloning without LFS installed technically succeeds, but Git replaces each tracked file with its small pointer file — so the files will appear in your working directory but be unusable.
• Hosted platforms (GitHub, GitLab, Bitbucket) include limited LFS storage and bandwidth; heavy use may require a paid plan.
• If your problem is a repository bloated with many small tracked files rather than a few large ones, LFS won't help. To stop tracking files going forward, use .gitignore; to scrub them from history entirely, use git filter-repo.

Learn More

• Check out the chapter Handling Large Files with LFS in our free online book