Skip to content
Preptima
mediumScenarioConceptDesignMidSeniorStaff

Your source control stores every version of a 200MB binary and the repository is now 40GB. What is being stored, and why can you not delete it?

Roughly 200 near-full copies, because delta compression works on text and a relinked binary differs throughout, so each version costs almost its own size. Deleting the file changes nothing: history is content-addressed and every past commit still reaches the blob. The design fix is that build outputs belong in a registry that can expire them, because version control is built never to forget.

6 min readUpdated 2026-08-15

Answer

Short answer

Large binaries in Git stay expensive because every historical commit can still reach the blob, so deleting the file from the latest revision does not shrink the repository. Use shallow or partial clones for immediate relief, move future binaries to Git LFS or an artifact registry, and rewrite history only as a coordinated migration.

Was this answer helpful?

Likely follow-ups

  • CI does 200 fresh clones a day. Which change do you make this week, and what does it not fix?
  • A build record from last year references a commit sha you are about to rewrite. What happens to it?
  • Someone commits a 200MB binary again next month. What stops them, and where does that check live?
  • Which binaries do legitimately belong in the repository, and what makes them different?

Related questions

Masterclass guide

Further reading