Git repository scaling and large files
What it is
Repository scaling keeps Git usable as history, file count, and team size grow. Git Large File Storage (LFS) stores large binary content outside normal Git object history; tools such as Scalar improve the experience of working with very large repositories.
Why it exists
Git handles source text efficiently, but repeatedly committing large binaries bloats clones, fetches, storage, and CI checkout time. A repository strategy must balance developer speed, history needs, and access boundaries.
Key ideas
- Use Git LFS for eligible large binary assets before they enter normal history. Adding a pattern later does not remove already-committed blobs.
- Consider repository boundaries, monorepo checkout strategy, sparse checkout, caching, and cross-repository sharing from the consumer and CI perspective.
- Use tags to identify immutable releases; branches are moving lines of development.
- Removing sensitive or oversized data from history is a remediation operation, not a normal
git rm. Coordinate force-push and clone replacement carefully.
Exam decision
Choose LFS when the problem is large binary assets. Choose repository scaling/checkout strategy when the problem is the working set of a very large source tree. Neither is a substitute for repository permissions.
Related
git · azure-repos · github · branching-strategy
Source: Manage large files in Git