A full clone downloads all history and content, which is wasteful when you only need recent work or a build. Shallow and partial clones reduce what is transferred, at the cost of some operations and offline behavior.
Before you start
You should be comfortable with cloning and history. This article covers shallow and partial clone options.
Step-by-step walkthrough
Step 1: Limit depth with a shallow clone
git clone --depth 1 fetches only the latest commit, which is enough for building or inspecting current code. History operations such as git log or git blame are limited, and you can deepen later with git fetch --deepen or --unshallow.
Step 2: Filter content with a partial clone
--filter=blob:none fetches commits and trees but not file contents, which are fetched on demand when you check out a file. This keeps the clone small while preserving full history, and it suits repositories with large blobs.
Step 3: Understand the network dependency
Partial clones fetch missing objects on demand, so some operations need network access and can be slower on a cold cache. CI that builds many branches may be better served by a full or carefully scoped clone, since on-demand fetching adds latency.
Worked scenario
A shallow, filtered clone fetches only what is needed now.
git clone --depth 1 --filter=blob:none https://example.com/repo.git
# later, to get full history:
git fetch --unshallowWalk through the example
The clone brings the latest commit and skips file contents, so it is small and fast. Checking out a file fetches its blob on demand. Deepening the clone later restores history when you need it, so the trade is reversible for shallow clones.
Common mistake
Using a shallow clone for a task that needs history, then hitting errors in log, blame or a merge base, because those commits are absent. Another is assuming a partial clone works fully offline, when missing objects are fetched lazily.
Verify the behavior
Compare clone size and time for full, shallow and filtered clones. Confirm git log depth is limited in a shallow clone, then unshallow and confirm history appears. Check out a file in a blobless clone and observe the on-demand fetch.
Interview exercise
When is a shallow clone a poor choice?
Answer and reasoning
When you need history: computing a merge base, running git blame, bisecting or building historical versions. A shallow clone lacks those commits, so the operations fail or force a re-fetch. For CI that only builds the current commit it is ideal; for investigation it is not.
Continue learning
Compare history recovery in Reflog recovery and pipeline use in Pipeline cache. Read the Git partial clone documentation and try the Git interview questions.