Introduction

A shallow clone can be updated normally, but you need to remember that its history is intentionally incomplete. Depending on what you need, updating may mean fetching the latest commits at the same shallow depth, deepening the history, or converting the clone into a full repository.

What a Shallow Clone Is

A shallow clone is created with a limited history, for example:

git clone --depth 1 https://example.com/repo.git

That gives you the newest visible snapshot plus only a small amount of commit history. It is useful for CI, large repositories, and quick read-only work, but it affects operations that need ancestry information.

Update the Latest History at the Current Depth

If you simply want the newest commits while remaining shallow, fetch and then fast-forward:

git fetch origin
git pull --ff-only

For many workflows, that is enough. Git keeps the repository shallow and updates the checked-out branch to the latest reachable commit.

If you want to be explicit about depth:

git fetch --depth 1 origin main
git checkout main
git pull --ff-only

This is common in automation where only the latest state matters.

Deepen the Clone

If the shallow history is too short for a merge, rebase, blame, or log operation, fetch more history without going fully deep:

git fetch --deepen 50 origin main

That adds 50 more commits of history behind the current shallow boundary.

You can also fetch to an absolute depth:

git fetch --depth 100 origin main

Use --deepen when you want to extend what you already have incrementally. Use --depth when you want the shallow history reset to a specific total depth.

Convert to a Full Clone

If the shallow restriction is now getting in the way, unshallow the repository:

git fetch --unshallow

After that, the clone behaves like a normal full clone and operations that depend on complete history become much more reliable.

This is often the right move when a shallow clone started as a CI optimization but the local work has evolved into real development.

Fetch Tags and Other Refs Carefully

Shallow clones often omit history and sometimes tags that older commits reference. If you need tags too:

git fetch --tags

Just remember that tag usefulness can still be limited if the associated commit history has not been fetched yet.

Likewise, if you need another branch, fetch that branch explicitly:

git fetch --depth 20 origin feature-x

Shallow clones are more explicit by nature. You do not always have the historical context for every branch unless you fetch it.

Why Some Operations Fail in Shallow Clones

Commands that need ancestry beyond the shallow boundary can misbehave or stop with errors. Common examples include:

• rebasing onto older history
• merge-base calculations
• some blame and bisect workflows
• scripts that assume full repository history

When this happens, the fix is usually not a special flag on the failing command. The fix is to fetch enough history for the command to make sense.

A Practical Update Sequence

A good decision flow is:

1. if you just need the newest snapshot, run git fetch and git pull --ff-only
2. if history-dependent commands fail, use --deepen
3. if the repo has effectively become a development clone, use --unshallow

That is cleaner than guessing blindly at depth values every time a command breaks.

Common Pitfalls

• Assuming a shallow clone updates differently from a normal clone for basic fetch and pull operations. The difference usually appears only when history depth matters.
• Using git pull blindly when the local branch cannot fast-forward cleanly and the missing history makes troubleshooting harder.
• Forgetting that rebases, merge-base logic, and history inspection often need more than a depth-1 clone can provide.
• Repeatedly increasing depth by trial and error when the real solution is simply git fetch --unshallow.
• Assuming tags or other branches are fully useful in a shallow clone without fetching the necessary related history.

Summary

• A shallow clone can be updated with normal fetch and pull commands.
• Use --deepen or --depth when you need more history but still want to stay shallow.
• Use --unshallow when the repository should become a normal full clone.
• Many shallow-clone problems are really history-availability problems, not update-command problems.
• Choose the smallest history that supports your actual workflow, then deepen only when needed.