Git LFS
debt(d7/e7/b7/t7)
Closest to 'only careful code review or runtime testing' (d7). The detection_hints note automated=no and tools like git-lfs and github-bfg require manual invocation. The problem — large binaries silently accumulating in git history — is not caught by default linters or compilers; it only becomes visible when clones become slow or repo size balloons in production, often after significant damage is done. A specialist can run `git lfs ls-files` or check repo size, but nothing flags the problem automatically at commit time without pre-commit hooks explicitly configured.
Closest to 'cross-cutting refactor across the codebase' (e7). The quick_fix notes LFS for new files, but common_mistakes explicitly state 'installing LFS after large files are already committed — past commits unchanged.' Remediation requires rewriting git history (BFG Repo Cleaner or git-filter-repo), coordinating all contributors to re-clone, updating CI/CD pipelines, and reconfiguring .gitattributes — a cross-cutting effort affecting the entire team's workflow and repository history.
Closest to 'strong gravitational pull' (b7). Once large binaries are committed to git history (or LFS is adopted), every contributor, CI system, and deployment pipeline is shaped by the choice. Applies_to is 'any' context. The repository size and clone time affect every future developer; LFS requires every contributor to have git-lfs installed and configured; bandwidth quotas must be planned for. The choice defines how the entire team interacts with assets going forward.
Closest to 'serious trap' (t7). The misconception field directly states the canonical trap: developers believe deleted binary files are gone from history, but every version is stored permanently and affects every clone. This contradicts how most version control systems appear to work (delete = gone) and how text files behave (delta-compressed). Additionally, installing LFS after the fact doesn't fix past commits — the 'obvious' remediation is incomplete. These are well-documented gotchas that contradict reasonable developer assumptions.
Also Known As
TL;DR
Explanation
Git LFS stores large files (images, videos, audio, design files, compiled binaries, datasets) outside the git object store. In the repository: a 134-byte text pointer file. On the LFS server: the actual binary content. Benefits: fast clone (no large binaries by default), full history accessible, file locking for exclusive edits. Commands: git lfs install, git lfs track '*.psd', commit .gitattributes. Providers: GitHub (1GB free), GitLab, Bitbucket all support LFS. Past commits with large files are unchanged — LFS only affects future commits.
Common Misconception
Why It Matters
Common Mistakes
- Installing LFS after large files are already committed — past commits unchanged
- Not committing .gitattributes — LFS tracking rules lost for other contributors
- LFS without bandwidth budget planning — LFS downloads count against provider quotas
- Tracking too many file types — small icons are fine in regular git
Code Examples
# Large files in regular git:
git add design-mockups/hero-video.mp4 # 250MB
git add design-mockups/assets.psd # 180MB
git commit -m 'Add design assets'
# Every clone now downloads 430MB for these files alone# Git LFS setup:
git lfs install
git lfs track '*.mp4' '*.psd' '*.ai' '*.sketch'
git add .gitattributes
git add design-mockups/hero-video.mp4 # LFS pointer: 134 bytes
git commit -m 'Add design assets (via LFS)'
# Clone: fast — pointer files only
# git lfs pull: downloads actual binaries when needed