What Is Git LFS?
Git LFS, or Large File Storage, replaces big files in your repository with small pointers, keeping the actual data in separate storage.
Git is built for text and struggles with large binary files like videos, datasets, or design assets, which bloat history and slow every clone. Git LFS solves this by storing those files outside the main history and leaving a lightweight pointer in their place, so the repository stays lean.
How Git LFS works
You tell LFS which file patterns to manage. For those files, Git stores a tiny text pointer in history while the real content lives in a dedicated LFS store. When you check out, LFS swaps the pointers for the actual files, so the experience feels seamless.
Setting up Git LFS
You install LFS, track a file type, and commit the resulting configuration.
git lfs install
git lfs track "*.psd"
git add .gitattributes design/logo.psd
git commit -m "Track PSD files with LFS"Why it helps
Without LFS, every version of a large binary is stored forever in history, so clones grow huge and slow. With LFS, history holds only small pointers, and the large data is fetched on demand. This keeps clones fast even for repositories full of media or binaries.
Git LFS in CI/CD
A CI runner must fetch LFS objects, or the build will see pointer files instead of real content. Checkout actions expose an LFS option to pull these objects. Because LFS data can be large, fetching it adds to job time and bandwidth, so enable it only for jobs that need the binaries.
Using LFS well
- Track only genuinely large or binary files with LFS.
- Commit the .gitattributes file so tracking is shared.
- Enable LFS fetching in CI for jobs that need the assets.
- Watch LFS bandwidth and storage quotas on your host.
Key takeaways
- Git LFS stores large files outside history, leaving pointers behind.
- It keeps clones fast even with media and binaries in the repo.
- CI must fetch LFS objects or it sees pointers, not real files.