Shallow Clone

Software projects are managed in so-called repositories — these are organized archives that store not only the current state of a project, but every single step ever made to it. This complete list of all changes can amount to gigabytes for large projects. A shallow clone is a deliberately incomplete copy of such an archive. Instead of the entire history, only the last few versions are downloaded. For many purposes, this is entirely sufficient — and it is considerably faster.

The difference to a full copy

With a normal clone, you download the complete history of a project: every intermediate state, every correction, every comment on it. The version control system Git stores this very efficiently, but with projects like the Linux kernel or large AI frameworks, a gigabyte or more quickly adds up anyway. This takes time — and requires storage that is often simply not needed.

A shallow clone cuts off this history at a certain point. You specify how many of the most recent versions you want — typically just the very latest. Everything before that is missing. The result is functional: the current code is completely present and runnable. The prior history is simply not included.

How Git implements the cut

In Git, you trigger a shallow clone with the --depth parameter, for example: git clone --depth 1 [address]. The number after it specifies how many consecutive versions should be transferred. With --depth 1, you get only the latest state, i.e. exactly one snapshot.

Internally, Git marks the oldest transferred point as an artificial boundary. The repository knows that something is missing there. Certain commands that require a comparison with older versions — such as git blame, which shows who wrote which line and when — therefore only work in a limited way or not at all. Anyone who later needs the full history can retrieve it with git fetch --unshallow.

A common misconception: a shallow clone is not a damaged or unsafe copy. The code itself is complete and intact. Only the historical metadata is missing. Anyone who just wants to build, test, or read it will, in practice, notice no difference.

Use in automated build systems

The most important place shallow clones are used is CI/CD pipelines — these are automated systems that independently run tests and build new versions with every change to the code. Such pipelines often start hundreds of times a day. Loading the entire repository history from scratch every single time would be pure waste.

Services like GitHub Actions, GitLab CI, or Jenkins therefore use shallow clones by default. The user often doesn’t even configure this themselves — it happens automatically in the background. A large repository that would take ten minutes to load as a full clone is ready in seconds as a shallow clone.

Shallow clones are also used when deploying AI models from public repositories — for example, when downloading model weights or training code from platforms like Hugging Face or GitHub — to fetch only the current state without dragging along years of development history.