Git Large File Handling Strategies for Binary Assets in Repositories

Git stores every version of every file forever, so large binary assets such as images, videos, and compiled artifacts make repositories slow to clone and hard to maintain. The main strategies are to keep binaries out of Git entirely, store pointers in Git with the real files elsewhere, or use partial clones to limit what developers download. The best choice depends on how often the files change and who needs them.

Why Do Large Binaries Hurt Git Repositories?

Git is designed around text. It compresses and deduplicates content, and it computes differences between versions efficiently when files are textual. Binary files often change completely with each edit, so each new version adds nearly its full size to the repository history.

The damage is permanent. Even after deleting a large file in a later commit, every clone still downloads it as part of the history. A repository can grow to gigabytes from a few careless commits, making clones slow, CI jobs expensive, and storage quotas on hosting platforms a problem.

Hosting platforms also impose size limits on files and repositories, and they can reject pushes that exceed them. Learning your platform's limits early prevents unpleasant surprises when a push suddenly fails.

What Are the Main Strategies?

There is no single best answer. Each approach trades simplicity against convenience and workflow.

• Keep binaries out of the repository: store build artifacts and generated files in an artifact registry or object storage, and reference them by version or checksum. Compiled output should almost never be committed.
• Pointer-based storage: tools such as Git LFS replace large files in the repository with small text pointers, while the actual content lives on a separate server and is downloaded on demand.
• External asset management: for large media libraries, use dedicated storage and a download step in your build or setup scripts.
• Partial and shallow clones: reduce what is fetched by omitting old history or large objects, which helps CI and new contributors.

Pointer-based storage keeps the workflow close to normal Git, but it requires server support, extra configuration for every contributor, and care with quotas and bandwidth. Review the documentation of your hosting platform and the tool before adopting it.

How Do You Set Up Pointer-Based Tracking?

With Git LFS, you tell Git which file patterns to manage, and the tool records those rules in an attributes file that you commit. From then on, matching files are stored as pointers.

git lfs install
git lfs track "*.psd"
git add .gitattributes
git add design/logo.psd
git commit -m "chore: track design files with LFS"

Decide on the patterns before adding files, because tracking only applies to files added after the rule exists. Files already committed as regular objects remain in history until migrated. Make sure CI is configured to fetch the large files it needs, and consider caching them to save bandwidth.

How Do You Clean Up a Repository That Already Has Large Files?

Removing a file in a new commit does not shrink history. To reclaim space, you must rewrite history to drop or convert the objects, using a history rewriting tool. This changes commit hashes, so everyone must re-clone or carefully reset their copies, and open branches and pull requests need attention.

• Back up the repository first, and coordinate the rewrite with the whole team.
• Use a tool built for history rewriting, and follow its documentation for your Git version.
• Prefer a fresh clone after the rewrite, to drop the old objects locally.
• Remember that forks and caches elsewhere may still hold the old data.
• If a secret was in the file, rotating it matters more than cleaning history.

Prevent a repeat. Add patterns to the ignore file, set up a pre-commit or CI check that rejects files above a size limit, and write down the policy for assets in the contributing guide.

Frequently Asked Questions

Does deleting a large file reduce the repository size?

Not by itself. The file remains in history, so you must rewrite history to remove it.

Is Git LFS always the right answer?

No. It helps for versioned assets that must live with the code, but build artifacts belong in an artifact store, not in Git.

How large is too large for a Git file?

Platforms set their own limits, and performance degrades well before them. Many teams flag files above a few megabytes for review.

Can partial clones help developers?

Yes. They download objects on demand, which reduces clone time, though they depend on server support.

Summary

Keep generated binaries out of Git, use pointer-based storage or external storage for necessary assets, and enforce size limits automatically. Rewriting history is possible but disruptive, so prevent the problem early. Check the Git and hosting platform documentation.