Introduction

A normal git clone already downloads the remote branch references. The confusing part is that Git checks out only one local branch by default, so the other remote branches exist as remote-tracking refs until you create local branches that follow them.

What git clone Actually Gives You

When you run:

git clone https://example.com/repo.git

Git does more than just copy the default branch history. It fetches the repository objects and remote-tracking branches such as origin/feature-x and origin/release-1.

You can see them with:

git branch -r

That means you usually do not need a special clone command just to obtain remote branches. The branches are already there in remote-tracking form.

Check Out a Remote Branch Locally

To create a local branch that tracks a remote branch, check it out explicitly.

git switch --track origin/feature-x

Git creates a local branch named feature-x that tracks origin/feature-x.

The older equivalent is:

git checkout --track origin/feature-x

Once that is done, normal git pull and git push work in the expected tracking relationship.

Create Local Tracking Branches for All Remote Branches

Sometimes you really do want local branches for every remote branch. Git does not do that automatically because many repositories have dozens of branches you may never need.

A shell loop can create them:

1for remote in $(git branch -r | grep -v '->'); do
2  branch=${remote#origin/}
3  git branch --track "$branch" "$remote" 2>/dev/null || true
4done

Then fetch updates normally:

git fetch --all

This is useful for repository analysis, migration work, or offline inspection of many branches. It is not usually necessary for day-to-day feature development.

Why --mirror Is Different

You may see git clone --mirror suggested. That is not the usual answer for a working repository.

git clone --mirror https://example.com/repo.git

A mirror clone is mainly for repository replication, backup, or server-side mirroring. It creates a bare repository that mirrors refs, not a normal working tree where you edit code and switch branches casually.

So if the goal is "I want a normal clone and access to all branches," use a regular clone. If the goal is "I want an exact ref mirror of the remote," use --mirror.

Practical Workflow

For most developers, the simplest workflow is:

1. clone normally
2. inspect remote branches with git branch -r
3. check out only the branches you actually need

That keeps the local repository uncluttered and avoids dozens of stale local branches.

If you later need a remote branch you have never checked out, Git can create the tracking branch at that moment. There is no penalty for waiting.

Common Pitfalls

• Assuming git clone only downloads the default branch history is incorrect. Remote-tracking refs for other branches are usually fetched as part of the clone.
• Using --mirror when you really want a normal working copy creates the wrong repository shape. Mirror clones are for replication, not ordinary development.
• Creating local branches for every remote branch by default can clutter the repository with stale refs you never use. Check out only what you need unless there is a specific reason to materialize everything.
• Forgetting that remote branches appear under git branch -r can make it look like they are missing. Inspect remote-tracking branches before trying to fetch again.
• Treating local branches and remote-tracking branches as the same thing causes confusion. A local branch is yours to work on; a remote-tracking branch records the remote state.

Summary

• A normal git clone already fetches remote branch references.
• Only one local branch is checked out by default.
• Use git switch --track origin/<branch> to create a local tracking branch.
• Create local branches for all remotes only if you actually need them.
• 'git clone --mirror is for mirroring repositories, not standard development clones.'