What does git clone --mirror give you that a plain bare clone does not?
answer
- both lack a working tree
- one of them keeps a mapping rule
- every ref, not just branches
- updates overwrite rather than merge
- the push counterpart deletes
basics
~20 sA mirror clone is bare and additionally maps every ref with +refs/:refs/, recording remote.origin.mirror, so an update overwrites all local refs with the remote's. A plain bare clone copies branch heads once and sets up no such tracking.
solid answer
~50 s`git clone --bare` gives you a repository with no working tree whose branch heads are copied straight into `refs/heads/`, with no remote-tracking configuration. `git clone --mirror` implies `--bare` but goes further: it maps all refs — branches, tags, notes, even the source's own remote-tracking refs — by configuring `remote.origin.fetch = +refs/*:refs/*` and `remote.origin.mirror = true`, so `git remote update` or a fetch overwrites every local ref with the remote's current value. That makes it the right tool for a full backup or for moving a repository between servers, typically followed by `git push --mirror <newurl>`. It is not a working repository: there is no working tree, and its refs are not yours to keep — the next update replaces them. `git push --mirror` is likewise destructive on the destination, since refs absent locally are deleted there.
code
console · 8 lines$ git clone --mirror https://example.com/team/app.git
$ cd app.git
$ git config --get remote.origin.fetch
+refs/*:refs/*
$ git config --get remote.origin.mirror
true
$ git remote update # overwrites every local ref
$ git push --mirror https://example.net/team/app.gitgo deeper
Know that both bare and mirror clones have no working tree, and that a mirror is the option used to copy a whole repository somewhere else rather than to work in.
Explain the mechanism: mirror implies bare and configures a forced refspec covering all refs plus a mirror flag, so updates overwrite every local ref instead of only tracking branches.
Demonstrate migration judgment — mirror-clone then mirror-push, verify branches and tags arrived, and articulate why mirror pushes are destructive and must never be aimed at a live shared repository.
Own the policy for repository backups and moves: what a Git-level mirror does and does not capture, how often replicas refresh, and who is allowed to run a destructive mirror push.
## Bare versus mirror Both options produce a repository with no working tree — the object database and refs, laid out as the contents of what is normally the `.git` directory. They differ in the ref mapping. `git clone --bare` copies the source's branch heads directly into the new repository's own `refs/heads/`, without mapping them into a `refs/remotes/origin/` namespace and without the remote-tracking configuration a normal clone gets. The result is a snapshot you can serve or push into; nothing keeps it in step with the source. `git clone --mirror` implies `--bare` and adds the mapping. It configures `remote.origin.fetch = +refs/*:refs/*` and sets `remote.origin.mirror = true`. That refspec is deliberately maximal: every ref under `refs/` on the source, whatever the namespace — branches, tags, notes, and the source's own remote-tracking refs — lands at the identical path locally, forcibly. So a mirror is a faithful copy of the entire ref graph, and it stays faithful when you refresh it. ## Refreshing a mirror Because the refspec is forced and covers everything, `git remote update` or a fetch in a mirror does not merge anything into anything — it overwrites. A branch that moved backwards on the source moves backwards in the mirror, and refs deleted upstream are removed under the mirror configuration. That is exactly what you want from a backup, and exactly what makes a mirror useless as a place to do work: any local ref you create risks being replaced on the next update, and there is no working tree to edit files in. ## Pushing a mirror The counterpart is `git push --mirror <url>`, which pushes every ref under `refs/` to the destination and deletes refs there that do not exist locally. It is how you complete a repository move: mirror-clone the old location, then mirror-push to the new one, and the destination ends up with the same branches, tags and notes rather than just the default branch. Treat it as destructive. Pointed at a live repository, a mirror push can delete branches other people are using, because make the destination match me is precisely its contract. Confirm the destination is empty or genuinely meant to be replaced, and remember that the source of truth in a mirror push is your local copy, however stale it is. ## Choosing between them - Use `--mirror` when you want a complete, refreshable copy: migrations, off-site backups, seeding an internal replica. - Use `--bare` when you just want a repository without a working tree that you will push into and serve from, and you do not want it overwriting refs from an upstream. - Use a normal clone whenever a human will edit files. Neither bare nor mirror has a working tree, so nothing can be checked out in place. ## Configuring mirroring on an existing remote The behaviour is config, not magic. `git remote add --mirror=fetch <name> <url>` gives an existing repository a remote whose fetch overwrites all local refs; `--mirror=push` makes pushes to that remote behave like `git push --mirror`. Both are sharp tools — `--mirror=push` in a repository where you also work means an ordinary `git push <name>` can delete remote branches. ## What a mirror does not guarantee A mirror copies refs and the objects they reach. It is a Git-level copy, so anything a hosting system stores outside the Git ref graph is simply not part of it — describe a mirror clone as a complete backup of the repository's refs and objects, not of everything associated with a project.
- Why is git push --mirror dangerous against a shared repository?Its contract is to make the destination match your local refs exactly, so it force-updates every ref and deletes any that you do not have. Pointed at a live repository it can wipe branches and tags other people depend on. Use it only for migrations into a destination that is empty or meant to be replaced.
- Can you work in a mirror clone?Not sensibly. It is bare, so there is no working tree to edit, and its fetch refspec forcibly overwrites every local ref, so branches or commits you create can be replaced on the next update. Clone normally from the mirror if you need a repository to work in.
- How do you add mirroring behaviour to a remote in an existing repository?git remote add --mirror=fetch <name> <url> configures a remote whose fetch maps all refs and overwrites local ones, while --mirror=push makes ordinary pushes to that remote behave like a mirror push. The push variant is risky in a repository where you also do normal work.
A bare clone is a photocopy taken once; a mirror is a synchronised duplicate whose pages are replaced wholesale each time the original changes.
saying these in an interview costs you the question
- Says a mirror clone is just a bare clone with a different name
- Thinks you can check out and work in a mirror
- Uses git push --mirror against a live shared repository
- Believes a bare clone stays in sync with the source automatically
- Claims a mirror copies everything a hosting system stores