Git LFS & Large Files
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.
Learn Git LFS & Large Files in our free Git course — a beginner-friendly interactive lesson with worked examples, a practice exercise and a quick reference.
Part of the free Git course at LearnCodingFast — hands-on lessons with examples you run in your browser, plus practice exercises and a quick quiz.
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.
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.
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.
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.
Your turn. Install LFS, track a file type, and list managed files. Fill in the three blanks.
📋 Quick Reference
No commands given this time — just the plan. Show that LFS keeps a binary out of normal history.
Practice quiz
What problem does Git LFS solve?
- Large binary files bloating normal Git history and repository size
- Merge conflicts in text files
- Branches that have diverged
- Slow network connections only
Answer: Large binary files bloating normal Git history and repository size. Git stores a full new copy of a binary on every change, so large files balloon the repository; LFS keeps them out of the normal history.
What does git lfs track "*.psd" do?
- Compresses PSD files
- Deletes all PSD files
- Records a rule in .gitattributes so matching files are handled by LFS
- Uploads PSDs immediately
Answer: Records a rule in .gitattributes so matching files are handled by LFS. git lfs track writes a pattern into .gitattributes telling Git to route matching files through LFS.
Which file must you commit for LFS tracking rules to take effect for collaborators?
- .git/config
- .gitattributes
- .gitignore
- .lfsconfig only
Answer: .gitattributes. Tracking rules live in .gitattributes; committing it ensures everyone cloning the repo uses LFS for those patterns.
What is actually stored IN the Git repository for an LFS-tracked file?
- Nothing at all
- A thumbnail image
- The full binary, compressed
- A small text pointer file referencing the object
Answer: A small text pointer file referencing the object. Git stores a tiny pointer file (an oid hash and size); the real binary lives on the LFS server.
Where does the real binary content of an LFS file live?
- On a separate LFS server/store, fetched on checkout
- In .gitignore
- Only in your browser cache
- Inside .git/objects like any commit
Answer: On a separate LFS server/store, fetched on checkout. LFS keeps the actual large object on a dedicated LFS store and downloads it when you check the file out.
Which command must you run once to set up the LFS hooks and filters?
- git lfs enable
- git lfs install
- git install lfs
- git lfs start
Answer: git lfs install. git lfs install configures the smudge/clean filters and hooks so LFS engages automatically.
How do you list which files in the repo are managed by LFS?
- git lfs show
- git ls-lfs
- git lfs status --all
- git lfs ls-files
Answer: git lfs ls-files. git lfs ls-files prints each LFS-tracked file along with its object id.
You have a repo whose history already contains large binaries committed normally. Which tool rewrites history to move them into LFS?
- git lfs pull
- git lfs prune
- git lfs migrate
- git lfs track
Answer: git lfs migrate. git lfs migrate rewrites existing history so previously committed large files are converted to LFS pointers.
Why do huge binaries committed the normal way bloat Git history so badly?
- Git refuses to compress them
- Git stores a complete new copy of the whole file on every change, and every clone carries all of them forever
- They corrupt the index
- They are stored twice on purpose
Answer: Git stores a complete new copy of the whole file on every change, and every clone carries all of them forever. Binaries don't delta well, so each edit adds another full copy that lives in history forever and ships with every clone.
What commonly limits how much you can store and transfer with a hosted LFS service?
- Storage and bandwidth quotas set by the hosting provider
- The length of commit messages
- The number of collaborators
- The number of branches
Answer: Storage and bandwidth quotas set by the hosting provider. LFS hosting typically enforces storage and bandwidth quotas, so large or busy repos can exceed plan limits.