Clone and use all remote Git branches

A normal, unrestricted git clone creates remote-tracking refs for the remote branches it can fetch. It usually creates and checks out just one local branch initially. You do not need a separate clone for every branch.

git clone https://github.com/example/repo.git
cd repo
git branch -r
git switch --track origin/develop

The explicit switch creates a local develop tracking origin/develop. git switch develop can infer that relationship when there is one matching remote-tracking branch and branch guessing is enabled. Multiple matching remotes can make the inference ambiguous.

Check restrictions on the clone

--single-branch, a shallow clone that implies it, or a narrow fetch refspec can limit which branch refs are available. Partial clones can also omit some objects until needed. To expand an existing single-branch fetch configuration:

git remote set-branches origin '*'
git fetch origin
git branch -r

This changes branch selection; it does not automatically remove a shallow-history boundary or retrieve inaccessible server refs.

Create local branches in bulk when necessary

Usually, create each local branch when you need to work on it. If another tool requires local branches for all fetched origin branches, this POSIX-shell loop skips symbolic refs and existing local branches:

git for-each-ref --format='%(refname) %(symref)' refs/remotes/origin/ |
while read -r ref symbolic; do
  [ -n "$symbolic" ] && continue
  name=${ref#refs/remotes/origin/}
  git show-ref --verify --quiet "refs/heads/$name" && continue
  git branch --track "$name" "$ref" || break
done

It operates only on origin, does not switch the working tree, and leaves errors visible. Git refnames cannot contain whitespace, which makes this two-field format suitable here.

Use a mirror for a deliberate migration

git clone --mirror https://github.com/example/repo.git repo.git
cd repo.git
git remote update --prune

A mirror is bare and has no working tree. It maps all available refs and configures subsequent updates to mirror them. A plain --bare clone does not configure the same all-refs mapping.

After reviewing a destination intended to become a mirror, a migration may use git push --mirror DESTINATION_URL. That push can force-update and delete destination refs; it is not a generic safe backup command. Server-hidden refs and access restrictions still apply.

What is outside the mirror?

Issues, pull-request records, permissions, and release assets are platform data. A wiki may be a separate Git repository. Submodule repositories and Git LFS payloads also need separate handling; mirroring the main Git refs is not a complete hosting-platform backup.

A periodically updated mirror reflects deletions and rewritten refs. Keep retained snapshots or another recovery policy if you need historical backup protection rather than only the latest mirror.

See git-clone and git-push.