Managing large files
Design a strategy for managing large files
Why binaries hurt Git
Git stores text efficiently because successive versions delta well against each other. Binary files do not: a small edit to an image or archive produces a largely different file, so Git stores something close to a full copy every time.
The consequence is cumulative and permanent. Every clone fetches the entire history, so a binary committed once and deleted later still costs every developer, forever.
The three-way split
Use Git for source files, Azure Artifacts for dependencies, and Git LFS for large binary files that change often.
| Content | Store in |
|---|---|
| Source code | Git |
| Third-party or built dependencies | Azure Artifacts |
| Large binaries that change often — design assets, media | Git LFS |
The middle row is the one teams miss: a compiled dependency does not belong in the repository at all, and moving it to a package feed removes the problem rather than managing it.
How LFS works
LFS replaces the file in Git with a small pointer, storing the content separately and fetching it on checkout. History stays small while the working tree looks normal.
git-fat solves the same problem by a similar pointer mechanism and appears in the objectives, but LFS is the mainstream choice.
Repository health
Microsoft's guidance is to keep repositories small for clone and maintenance performance, and to reach for Git LFS, Scalar or Azure Artifacts when they grow. Adding LFS does not shrink existing history — you must rewrite it, which rewrites every commit hash.
Primary sources