Every so often we open a client codebase and find something that is not exactly a codebase. The application source is in there somewhere, but it is surrounded by years of accumulation: generated HTML reports, exported data, binaries, uploaded documents, archived copies of directories with names like backup_final_v2. The whole thing weighs hundreds of gigabytes, and it has worked, in its way, for a decade.
This happens for an understandable reason. When an application generates output and the output needs to live somewhere, the path of least resistance is next to the code. Do that weekly for ten years, without source control enforcing a boundary, and the codebase quietly becomes the company archive. Nobody decided this. It accreted.
Then one day there is a reason to put the code in Git, often a security event or a new developer, and the team discovers that "just push it to GitHub" is not a plan. You cannot meaningfully version-control 200GB of mixed source and data, most Git hosts will refuse to try, and even if one accepted it, you would have a slow, unreviewable repository where real changes drown in noise.
Why this is worth treating as a project
The instinct is to treat the cleanup as a chore someone can do in an afternoon of judicious deleting. Resist that instinct, for three reasons.
First, in these codebases, live code is not reliably separable from generated output by looking. Templates reference report directories. Scheduled jobs write into paths that other code reads back. Some of that "archive" is load-bearing. Deleting by eyeball is how you find out which parts, in production.
Second, the archive half of the repository is often the only copy of business records: reports customers received, exports regulators might ask about. Moving it is fine. Losing it is not. That makes this a data custody exercise wearing a code cleanup costume.
Third, the repository got this way because there was no boundary between code and data. If you clean it up without building that boundary, it will regrow. The deliverable is not a smaller directory; it is a rule the system enforces from now on.
The untangling, in order
Inventory before touching. Classify what is actually in there: application source, configuration, static assets the app serves, generated output, uploaded content, backups, and genuine mysteries. Sizes and last-modified dates do a lot of the work. This is discovery, and it deserves the name; on codebases like this we stop mid-call rather than guess live, because confident classification requires actually tracing what reads and writes each path.
Define the source-of-truth boundary. Code and configuration belong in Git. Generated output and uploads belong in object storage or a file server with its own retention story. Backups belong in a backup system, not a folder named old. Write the boundary down as a short policy anyone can apply to the next ambiguous file.
Relocate data with continuity. Move the archive tiers to their new homes first, verify the application still runs, and only then remove them from the working tree. Update the paths the application writes to, so tomorrow's reports land in the new location. This ordering means at no point is the archive homeless.
Then, and only then, initialize the repository. With the data gone, what remains is a normal-sized codebase that Git can hold. Add a .gitignore that encodes the boundary, so generated output cannot creep back in. History for the pre-Git era lives in the archived copies; trying to synthesize years of retroactive commit history is effort spent on an artifact nobody will read.
Finish with the working agreement. A repository is a practice, not a place. Branching, review, and deployment from the repo instead of live file edits, plus an hour of hands-on Git training for the people who will live in it. Skipping this step is how the same organization ends up doing the same cleanup again in five years.
The honest caveat
Sometimes the inventory comes back and the real finding is that untangling is not the right spend, because the application around the archive is itself due for replacement, and the modernize-or-rewrite decision should be made first. The 200GB repository is occasionally the symptom that finally gets the estate a clear-eyed look. That is not a failure of the cleanup project. That is the cleanup project doing its most valuable work: telling you what you actually have.
This kind of remediation and modernization work, discovery first, is our standing practice. If your repository has become your archive, our legacy modernization team has untangled worse, and we are happy to talk through it.