How to Maintain a Lightning-Fast Local Environment Without Cloning Your Entire Monorepo

There’s a specific kind of dread that sets in when you join a new team and the onboarding docs tell you to "grab a coffee" while the repo clones. It’s usually a sign that you’re about to sacrifice 40GB of your SSD to a monorepo containing three years of legacy marketing assets, ten microservices you'll never touch, and a documentation folder that hasn't been updated since 2019.

Most of us just accept this as the cost of doing business. We let git status take five seconds to run and pretend our fans aren't spinning at max speed because the IDE is indexing 200,000 files it doesn't need to know about.

But you don't actually need the whole thing. You just need the part you're working on.

The "Blobless" Clone

Before we even talk about specific folders, we need to fix how we get the data. Usually, when you clone, you get every version of every file ever. That’s a lot of baggage.

If you want to be fast, start with a "blobless" clone. This tells Git: "Give me all the commit history so my logs and branches work, but don't download the actual file contents until I specifically ask for them."

git clone --filter=blob:none --no-checkout https://github.com/org/massive-monorepo.git
cd massive-monorepo

The --no-checkout flag is key here. It prevents Git from trying to dump the entire file tree onto your disk immediately. At this point, your folder is tiny.

Defining Your Workspace

Now we use git sparse-checkout. This is the tool that tells Git to only populate your working directory with specific folders.

First, initialize the sparse-checkout state:

git sparse-checkout init --cone

The --cone flag is important. It restricts you to matching patterns based on directories (rather than complex regular expressions), which makes Git significantly faster because it can optimize how it handles the index.

Now, let’s say you only care about the identity service and the shared UI library:

git sparse-checkout set services/identity packages/shared-ui

Suddenly, your file explorer clears out. The thousands of other folders are gone. They still exist in the "cloud," but they aren't taking up space or CPU cycles on your machine. If you run ls, you’ll only see the stuff you actually need to see.

"I forgot a dependency"

Inevitably, you’ll try to run a build and realize services/identity depends on packages/utils, which you didn't check out. In the old days, you’d have to re-clone or mess with complex exclude patterns. Now, you just add it:

git sparse-checkout add packages/utils

Git fetches the missing blobs for that folder, stays fast, and keeps the rest of the junk out of your way.

Why this actually matters for your sanity

It isn't just about disk space. Disk space is cheap. It’s about latency.

When your local environment only has 500 files instead of 50,000:
1. git status is instantaneous.
2. Your IDE (VS Code, IntelliJ, etc.) stops eating 4GB of RAM just to provide autocomplete.
3. Global searches (Ctrl+Shift+F) actually return relevant results instead of noise from legacy-v1-dont-use.
4. Tests run faster because the file watcher isn't sweating.

The "Gotchas"

There are a few things that might trip you up.

If your project uses a build tool that expects to find a package.json or a go.mod in the root (most do), Git usually handles this fine—root-level files are typically included in a sparse checkout by default. However, if your build logic relies on scanning every folder in the repo to "auto-discover" services, that logic might break. You'll have to explicitly add those folders so the build tool can see them.

Also, remember that git grep will only search the files you have checked out. If you need to find something in the "dark" part of the repo, you'll either need to use a web-based code search (like GitHub's) or temporarily pull in those folders.

Back to Normal

If you ever decide you hate being productive and want the bloat back, you can disable it easily:

git sparse-checkout disable

This brings back everything. But once you've experienced a 20ms git status in a 10-gigabyte repo, you probably won't want to go back. Your laptop—and your patience—will thank you.