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.
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
- A transform has been writing wrong revenue figures for three days and six downstream tables have consumed it. How do you backfill the corrected data without double-counting anything?hardSame kind of round: scenario4 min
- Your consumer-driven contract test passes in CI, but production rejects a request because a supposedly optional field is missing. What did the contract testing actually miss?hardSame kind of round: concept4 min
- Your error budget burn alert pages every few hours, but half the time nobody outside the team has noticed anything. How do you tune it without simply making it quieter?hardSame kind of round: concept5 min
- Two clients open the same record, both edit it, and the second save silently overwrites the first. How would you use ETags to turn that lost update into something the client can see and handle?mediumSame kind of round: concept4 min