Some client codebases we open are not really codebases. The application source is in there, surrounded by years of generated HTML reports, data exports, binaries, uploaded documents, and folders named backup_final_v2. The total runs to hundreds of gigabytes, and the application has worked that way for a decade.
The way to get a codebase like this into Git is to move the data out first and version the code second. Inventory what is there, decide which system owns each kind of file, relocate the data without breaking the application, and only then create the repository. Reverse that order and you either break production or build a repository nobody can use.
How a codebase turns into an archive
An application produces output, the output needs a home, and the nearest home is next to the code. Repeat that every week for ten years with no source control to draw a line, and the codebase becomes the company archive. Nobody chose it. It accumulated.
Then something forces the question, often a security event or a new developer, and someone suggests pushing the whole thing to GitHub.
Why can't you just push it to GitHub?
You can't, because Git hosts are built for source code, not archives. GitHub's documentation on large files warns on files over 50 MiB, blocks files over 100 MiB, and recommends that repositories stay under 1 GB, with under 5 GB "strongly recommended." A 200GB mix of source and data is far past that. Even if a host accepted it, every real change would drown in noise.
Git Large File Storage (Git LFS) is the usual suggestion. It keeps a small pointer file in the repository and stores the real file somewhere else. That suits binaries that belong with the code. For ten years of report output, it hides the bulk and leaves code and data as tangled as before.
Why deleting by eye goes wrong
Cleaning up a codebase like this looks like an afternoon of careful deleting. It is a project, for three reasons.
Live code and generated output look alike. Templates reference report folders. Scheduled jobs write files that other code reads back later. Part of the "archive" is load-bearing, and deleting by eye is how you learn which part, in production.
The archive may be the only copy of business records. Reports customers received and exports a regulator could ask for often exist nowhere else. Moving them is fine. Losing them is not. This is a data custody job that looks like a code cleanup.
The mess regrows without a boundary. The codebase got this way because nothing separated code from data. Clean it without adding that separation and it grows back. The deliverable is not a smaller folder. It is a rule the system enforces.
How to move the codebase into Git, in order
A source-of-truth boundary is a written rule that names which system owns each kind of file: Git for code and configuration, object storage or a file server for generated output and uploads, a backup system for backups. Every step below builds or enforces that boundary.
Inventory before you touch anything. Classify every top-level path: application source, configuration, static assets the app serves, generated output, uploads, backups, and unknowns. File sizes and last-modified dates do much of the work. The rest needs tracing: which code writes each path, and which code reads it. This is discovery. On calls about codebases like this, we stop and take the question away rather than guess live.
Write the boundary down. Keep it short enough to apply to the next file nobody recognizes. A folder named old is not a backup system.
Move the data before you remove it. Copy each data tier to its new home. Point the application's write paths at the new location, so tomorrow's reports land there. Confirm the application still runs. Only then remove the data from the working tree. The archive never goes without a home.
Create the repository last. What remains is a normal-sized codebase that Git holds without complaint. Add a .gitignore file that encodes the boundary, so generated output cannot creep back in. Before the first commit, move credentials out of configuration files. A codebase that never lived in source control often keeps them in plain text, and leaked keys turn into a 24-hour emergency. Skip rebuilding pre-Git commit history. The archived copies already hold it, and nobody will read a synthetic log.
Agree how the team works now. A repository is a practice, not a place. Branch, review, and deploy from the repository instead of editing live files, and give the people who will work in it an hour of hands-on Git training. Skip this step and the same organization runs the same cleanup again in five years.
When the inventory says stop
Sometimes the inventory shows that untangling is the wrong spend. The application around the archive is due for replacement, and the decision to modernize, rewrite, or leave the app alone comes first. A 200GB repository is sometimes the symptom that finally gets an older system a clear-eyed review. That is not a failed cleanup. It is the cleanup doing its most useful work: telling you what you have.
If your repository has become your archive, our ColdFusion and legacy modernization team has untangled worse, and we are glad to talk it through.