Clone Large Repositories Faster

Partial clone downloads your project's history without every old version of every file — the files you actually check out arrive when you need them.

TL;DR — The Short Version

Clone with git clone --filter=blob:none followed by the clone URL from the repository's Clone button. No server setting or plan is needed — it works on every UnityFreak repository.
You get the full commit and directory history immediately, and Git fetches file contents on demand — first for the files in your checkout, later for anything else you open.
It pays off most on repositories with a long history of large or frequently changed files. For a small repository a normal clone is just as quick.
It needs Git 2.19 or newer on your machine (check with git --version); the sparse-checkout commands in section 6 need 2.25 or newer.

1. What partial clone does

A normal git clone downloads every version of every file that has ever existed in the repository. For a game project that has carried textures, scenes and binaries for years, most of that data belongs to old revisions you will probably never open.

A partial clone asks the server to leave file contents (Git calls them blobs) out of the initial download. You still receive every commit and the full directory structure, so branches, tags, git log and history graphs work straight away. The server records that this repository is the source for the missing contents, and your Git client downloads a file version the first time something needs it.

UnityFreak's Git servers accept this request over both HTTPS and SSH clone URLs. There is nothing to enable on the repository.

2. Quickstart

Copy the clone URL from the repository's Clone button (HTTPS or SSH) and add the filter option:

git clone --filter=blob:none <clone-url>
cd <repository>
git log --oneline | head     # history is available immediately

Authentication is exactly the same as for a normal clone: a personal access token over HTTPS (see importing a repository from another host for token basics) or your SSH key (see Push and Pull Over SSH).

Partial clone needs Git 2.19 or newer on your machine; an older client ignores or rejects --filter. Check with git --version.

You can confirm the clone is partial with:

git config remote.origin.partialclonefilter    # prints: blob:none
git config remote.origin.promisor             # prints: true

3. When it helps

Repositories with years of history and many large or frequently re-saved files (scenes, prefabs, generated assets, vendored libraries).
CI jobs and build machines that only need the latest checkout and a commit graph.
Quick inspection clones — reading a project, bisecting by commit message, or checking a branch — where you do not need every old file version on disk.

It helps less when you will read most of the history's file contents anyway (for example a full-history analysis), or when the repository is small.

4. What to expect afterwards

The first checkout downloads the files in that checkout. A partial clone still fetches the contents of the branch you check out, so the saving comes from skipping the history, not the working tree.
Commands that touch old versions need the network. git blame, git log -p, git diff across old commits and checking out an old tag download the missing file versions the first time. Later runs reuse what was fetched.
Working offline is limited to the files you have already opened. If you plan to work disconnected, use a normal clone instead.
Pushing is unchanged. Commits, branches, pull requests and branch protection behave exactly as in a full clone.

5. With Git LFS

Partial clone and Git LFS solve different halves of the same problem and work together. LFS keeps the huge files out of Git's object store (Git holds only a small pointer text file); partial clone keeps old versions of the ordinary files — including those small pointers — out of your first download. Keep running git lfs install once per machine as described in Large Files on UnityFreak; LFS content itself is downloaded by LFS on checkout exactly as before, and --filter does not change which large files you receive.

One caveat: the small pointer files of OLD revisions are ordinary Git objects, and a partial clone does not have them locally. Day-to-day work (clone, checkout, pull, push, branch switching) is unaffected, but the Git LFS commands that walk history — git lfs fetch --all, git lfs prune, git lfs push --all and git lfs migrate — have to read every old pointer and fetch the missing ones from the server one by one, which is slow on a repository with a long history. For those jobs use a full clone (or git fetch --refetch first, Git 2.36 or newer).

6. With sparse checkout

If you only work in one part of a large repository, combine the filter with a sparse checkout so Git also skips the files outside that folder. Cloning with both --filter and --sparse, and git sparse-checkout set, need Git 2.25 or newer:

git clone --filter=blob:none --sparse <clone-url>
cd <repository>
git sparse-checkout set Assets/Characters

Only the blobs for the folders you list are downloaded; the rest of the project stays on the server until you widen the set.

7. Troubleshooting

A command pauses while it fetches missing objects — that is the on-demand download described above. It needs a connection and your credentials, the same as a normal fetch.
Want everything locally after all? Clone the repository again without the --filter option into a new folder.