How to ‘Hack’ Git Clone Speed for Multi-GB Repositories – ITFROMZERO

Table of Contents

A 2 AM Nightmare with a 20GB Repo

The clock strikes 2 AM. I’m on duty to deploy an urgent hotfix. Suddenly, the CI/CD pipeline throws a ‘Timeout’ error. Checking the logs, I’m horrified to see the git clone step has taken 15 minutes and is still not finished. This repo has accumulated over 10 years of history, weighing nearly 20GB with dozens of ancient binary files.

If I just sit there waiting to pull all that data, the client will have my head. In a moment of desperation, I remembered something. I don’t need the project’s entire “family tree” just to fix a few lines of code. That’s when Shallow Clone and Partial Clone became my lifesavers. If you’re also tired of going to make coffee only to come back and find Git still cloning, this article is for you.

Quick Fix: Speed Up Clones in 30 Seconds

In a hurry and just want the code to fix a bug? Try one of these two commands:

Method 1: Get Only the Latest Commit (Shallow Clone)

git clone --depth 1 https://github.com/user/huge-repo.git

This command skips the entire history. It only downloads the latest state of the code. The result? Download size drops from 5GB to about 100MB in an instant.

Method 2: Get Every Commit but Skip Heavy Files (Partial Clone)

git clone --filter=blob:none https://github.com/user/huge-repo.git

This method is smarter. It downloads the entire commit history but “forgets” the files (blobs). Git only actually downloads a file when you need it (for example, when checking out another branch).

Why is Your Repo So Bloated?

By default, the git clone command downloads everything. From every version of every file to every branch and tag since day one. For long-standing Monorepo projects, this is a massive burden on both bandwidth and disk space.

1. Shallow Clone (–depth) – Just the Tip

Imagine reading only the last chapter of a novel instead of starting from the beginning. --depth 1 creates a truncated history.

Pros: Extremely fast, maximum storage savings.
Cons: You can’t view git log for old commits. Sometimes pushing or merging will fail because Git lacks info about parent commits.

I once learned a hard lesson with Shallow Clone on Jenkins. Due to the missing history, the SonarQube tool couldn’t run git blame to assign bugs to the right person. The reports were a complete mess. Therefore, you should only use Shallow Clone for build or quick test tasks.

2. Partial Clone (–filter) – On-Demand File Downloads

This feature appeared in Git 2.20 and is truly a revolution. It keeps the commit structure intact but leaves the file contents on the server.

There are two common filters you should remember:

--filter=blob:none: Doesn’t download any files until checkout. This is the best balance between speed and flexibility.
--filter=blob:limit=1m: Only downloads files smaller than 1MB. Large files like images, videos, or binaries stay on the server until you actually touch them.

Advanced Technique: Combining with Sparse Checkout

Only need the /frontend folder in a massive Monorepo containing Backend and Mobile? Don’t download everything. Use the Partial Clone + Sparse Checkout combo.

# 1. Clone but don't download files, no checkout
git clone --filter=blob:none --no-checkout https://github.com/user/huge-repo.git
cd huge-repo

# 2. Specify the directory you actually need
git sparse-checkout set web-app/src

# 3. Checkout to get files for that folder
git checkout main

This method helps you save download time while avoiding thousands of junk files on your machine.

Real-world Experience: Which One Should You Choose?

After many “sweaty” encounters with legacy systems, here is my rule of thumb:

Use Shallow Clone (–depth) when:

Running CI/CD pipelines (build and then delete immediately).
Need a quick hotfix on production servers without waiting.
You’re sure you don’t need to rebase or look deep into the history.

Use Partial Clone (–filter) when:

Working long-term on a project with a very heavy repo.
Need to use git log or git blame to investigate code history.
Want to save disk space while keeping all of Git’s power.

I once accidentally force pushed to the wrong branch on a shallow clone because I couldn’t see the full history. The hard-earned lesson is: always prioritize Partial Clone for personal machines. Only use Shallow Clone for Virtual Machines (VMs) or Docker containers.

Wrapping Up

Mastering your tools is the best way to keep your creative flow. Understanding Shallow and Partial Clone helps reduce frustration when working on large projects. It also makes your team’s CI/CD systems run much smoother. Don’t let a frozen git clone progress bar discourage you. Try applying this to your project right away—the difference will surprise you!