Git LFS & Large Files

Reviewed & published by Brayan K

Big binaries — PSDs, datasets, videos — wreck a normal Git repo, because Git stores a full new copy on every change. Git Large File Storage keeps them out of your history, storing tiny pointers in the repo and the real files on an LFS server. This lesson covers installing, tracking, pointers, listing, migrating, and quotas.

Part of the free Git course at LearnCodingFast — hands-on lessons with worked examples and the output they print, plus practice exercises and a quick quiz.

What You'll Learn

• Set up LFS with git lfs install
• Track file types with git lfs track and .gitattributes
• How pointer files replace binaries in history
• List managed files with git lfs ls-files
• Convert existing files with git lfs migrate
• Why big binaries bloat history, plus storage quotas

1️⃣ Installing & Tracking

Run git lfs install once to wire up LFS's filters and hooks, then git lfs track "*.psd" to manage a file type. Tracking writes a rule into .gitattributes — commit that file so everyone who clones the repo uses LFS for those patterns too.

# Git LFS is an extension — install it once per machine, then per repo.

# 1) One-time setup of the LFS filters and hooks for your account
git lfs install
#   Updated Git hooks.
#   Git LFS initialized.

# 2) Tell LFS which file types to manage in THIS repo
git lfs track "*.psd"
git lfs track "*.zip"

# This writes patterns into .gitattributes — commit that file!
cat .gitattributes

2️⃣ Pointer Files: How LFS Stores Things

You git add and git commit large files as normal, but what Git actually stores in the repo is a tiny pointer file — an oid hash and a size. The real binary is uploaded to the LFS server on push and fetched back on checkout. That's how history stays small.

# Add and commit a large file as usual — LFS handles it transparently.
git add design.psd .gitattributes
git commit -m "Add design source (via LFS)"

# What Git actually STORED in the repo is a tiny POINTER, not the 200MB file:
git show HEAD:design.psd

# The real binary was uploaded to the LFS server on push; the pointer
# (an oid hash + size) is all that lives in normal Git history.

3️⃣ Listing LFS Files

git lfs ls-files lists every file LFS manages, with its object id. Use it to confirm your big assets are genuinely going through LFS and weren't accidentally committed as normal blobs.

# Which files in this repo are managed by LFS? Ask LFS directly.
git lfs ls-files

# Each line shows the object id (shortened) and the file path.
# Use this to confirm your big assets are really going through LFS
# and aren't accidentally committed as normal blobs.

4️⃣ Migrating Existing Files

Already committed big binaries the normal way before adding LFS? git lfs migrate import --include="*.psd" rewrites history so those files become LFS pointers. Because it rewrites commits (new hashes), treat it like a rebase: coordinate with your team and only force-push when everyone's ready.

# Already committed big binaries the NORMAL way before adding LFS?
# Rewrite history to convert them into LFS pointers.

# Convert all *.psd in history to LFS (this REWRITES commits!)
git lfs migrate import --include="*.psd"

# Because history changed, hashes change — coordinate with your team
# and force-push only when everyone is ready (just like a rebase).
git push --force-with-lease

Your turn. Install LFS, track a file type, and list managed files. Fill in the three blanks.

# 🎯 YOUR TURN — replace each ___ then run it in your terminal.
# Goal: set up LFS in a repo and track a big binary type.

# 1) Initialize LFS for your account (one-time)
git lfs ___                         # 👉 the subcommand that sets up hooks/filters

# 2) Track all PSD files so LFS manages them
git lfs ___ "*.psd"                 # 👉 the subcommand that writes a rule to .gitattributes

# 3) Confirm which files LFS is now managing
git lfs ___                         # 👉 the subcommand that lists LFS files

# ✅ Expected: .gitattributes gains a "*.psd filter=lfs" line, and after you
#    add a PSD, "git lfs ls-files" lists it with an object id.

Common Errors (and the fix)

• Teammates get pointer text, not the file: they haven't run git lfs install or lack the extension. Install LFS, then re-checkout.
• Tracking didn't apply for others: you forgot to commit .gitattributes. Commit it so the rules ship with the repo.
• Repo still huge after adding LFS: existing big files are already in history. Use git lfs migrate to convert them.
• Push rejected by quota: you've hit the host's LFS storage or bandwidth limit. Prune unused objects or upgrade the plan.

Pro Tips

• 💡 Track before you commit: add the LFS rule first so the file never lands in normal history.
• 💡 Commit .gitattributes: it's what tells every clone to use LFS for those patterns.
• 💡 Track narrowly: only route file types that truly need LFS to conserve quota.
• 💡 Verify with ls-files: confirm big assets are managed, not accidentally inline.

📋 Quick Reference

Mini-Challenge: Prove the Pointer

No commands given this time — just the plan. Show that LFS keeps a binary out of normal history.

# 🎯 MINI-CHALLENGE: prove LFS keeps a binary out of normal history.
# No commands given — just the plan. Run each step in your terminal.
#
# 1. In a fresh repo, run "git lfs install" and track "*.bin"
# 2. Commit .gitattributes, then add and commit a multi-MB .bin file
# 3. Run "git show HEAD:yourfile.bin" — confirm you see a POINTER, not bytes
# 4. Run "git lfs ls-files" — confirm the file is listed as LFS-managed
# 5. Reflect: how would repo size differ if you'd committed it without LFS?
#
# ✅ Expected: the repository stores a tiny pointer while the real binary
#    lives in the LFS store, keeping normal history small.

# your commands here

🎉 Lesson Complete!

• ✅ git lfs install then git lfs track sets up LFS via .gitattributes
• ✅ The repo stores a tiny pointer; the real binary lives on the LFS server
• ✅ git lfs ls-files shows what's managed; git lfs migrate converts old files
• ✅ Huge binaries bloat normal history because Git copies them on every change
• ✅ Watch storage and bandwidth quotas on hosted LFS

Practice quiz

Continue this course

• Previous: Multiple Working Trees with git worktree
• Next: How Git Works Internally — Blobs, trees, commits and the DAG — what a SHA really points to
• Quick reference: Git cheat sheet

Frequently asked questions

What is Git LFS and why would I use it?

Git Large File Storage (LFS) is an extension that keeps big binary files — design assets, datasets, videos, archives — out of your normal Git history. Plain Git stores a complete new copy of a file every time it changes, and binaries don't compress between versions, so a repo full of large assets balloons and every clone has to download all of it forever. LFS replaces those files in history with tiny pointers and stores the real content on a separate server, keeping the repository fast and small.

How do I start tracking files with LFS?

Run git lfs install once to set up the LFS filters and hooks, then git lfs track "*.psd" (or whatever pattern) to manage a file type. That track command writes a rule into .gitattributes, so you must commit .gitattributes for the setup to work for everyone who clones the repo. After that, you git add and git commit large files exactly as normal — LFS intercepts them transparently.

What actually gets stored in the repository for an LFS file?

Instead of the binary, Git stores a small text pointer file containing an oid (a sha256 hash of the content) and the file's size. The real bytes are uploaded to the LFS server when you push and downloaded again when you check the file out. You can see the pointer with git show HEAD:file, and you can list every LFS-managed file in the repo with git lfs ls-files.

I already committed large files normally — can I move them into LFS?

Yes. git lfs migrate import --include="*.ext" rewrites your existing history so previously committed large files become LFS pointers. Because this rewrites commits (and therefore changes hashes), treat it like a rebase: coordinate with your team and only force-push once everyone is ready. Migrating is the standard fix when a repo has already grown bloated from binaries committed before LFS was set up.

Are there limits I should know about with hosted LFS?

Yes — LFS storage lives on a server, and hosting providers typically enforce storage and bandwidth quotas as part of their plans. A repo with many or frequently-changing large assets can hit those limits, so it's worth tracking only the file types that truly need LFS, pruning old LFS objects you no longer need, and being mindful of how often huge files change. Quotas are usually the first thing teams bump into as LFS usage grows.