2.4 GB repository, 180 MB assets, one sprint
An eight-person game studio stores its Unity project on GitHub. The repository is 2.4 GB; a fresh clone takes about 15 minutes on the office connection. Most of the size comes from roughly 300 Photoshop and audio source files, some 180 MB each, committed over the past two years by designers who drag files into the web uploader. Pushes of new large files now fail outright. The team also has six open pull requests, four of which touch the assets folder. Leadership asks for the repository to be clean and fast within one sprint, without losing any shipped asset.
1. The large assets are already in history. Compare the realistic options and recommend one given the one-sprint deadline.
Read the worked answer
Ignoring the files now only fixes the future; the 2.4 GB stays.
Rewrite history with Git LFS. Running something like git lfs migrate import --include="*.psd,*.wav" --everything replaces historical blobs with pointer files. Consequences the team must accept: every commit SHA in the rewritten range changes, every clone must be re-cloned or hard-reset, and all six open PRs need rebasing or reopening. It also moves cost rather than eliminating it, since LFS storage and bandwidth are billed.
Leave history, move the sources out. Put source art in release assets or external object storage, add ignore rules, and keep the code repository small. Repository size is unchanged and clones stay slow, but nothing breaks and no PRs are lost.
Given one sprint and six live PRs, the second is the lower-risk choice; the first is the only one that actually shrinks clone time. A hybrid is often right: stop the bleeding now, schedule the LFS migration for a quiet period when the PR queue is empty.
2. Pushes of new large files now fail. Explain what is blocking them and how the team should stop the problem recurring.
Read the worked answer
GitHub rejects pushes containing any single file over 100 MB outright and warns above 50 MB. That is a server-side rule, so it applies to the web uploader as well as the command line, which is why the drag-and-drop habit the designers have is now hitting a hard wall.
Prevention has to sit ahead of the uploader, since the uploader is the path being used:
- Add the source directories to
.gitignoreso designers do not see them as committable. - Add a CI check that fails a pull request containing any blob above a chosen threshold, which catches web uploads a local pre-commit hook cannot see.
- Document where large sources actually belong, and make that location as easy as dragging into GitHub.
- For people who only need a slice of the tree,
git clone --filter=blob:noneplus sparse-checkout makes a large history tolerable without rewriting it.
3. A designer insists that cloning 2.4 GB is fine on their machine and the rewrite is unnecessary. How do you frame the decision?
Read the worked answer
Frame it as a cost that is paid by everyone, repeatedly, versus once. Fifteen minutes per clone multiplied across eight people, CI runners, and every fresh machine is ongoing; the migration is a single disruptive day.
But do not oversell it. Be explicit about what the rewrite costs: open PRs must be rebased, old links to commits break, and anyone with unpushed work loses it if they pull naively. Agree the mechanics before starting: announce a freeze, have everyone push their branches, do the migration, then tell each person to re-clone rather than pull.
Also separate the two questions. Whether the history should be rewritten is a tooling decision; whether the team should keep storing art in a code repository is a policy decision. Answer the policy question first, because if sources move out anyway, the migration becomes optional cleanup rather than urgent work.