Duplicate a repository with full history
Whether you're migrating hosts or keeping a standing copy, the setup is the same — you just decide whether to leave it running.
One-time copy, or a duplicate that stays current
The underlying mechanism doesn't change — only whether you leave the binding running afterward.
One-time
Migrating to a new host, org, or account. Run the sync, verify branches and tags match, then deactivate the binding — there's nothing left to maintain.
Continuous
Leave the binding active and the duplicate tracks the original on every push — the same mechanism as a mirror, just framed around keeping a second copy rather than a live failover target.
What "full history" means
Every commit, every branch, every tag — not a squashed snapshot of the current state.
Every commit
The complete commit graph copies across — not a squashed snapshot of the current state. History, authorship and commit messages are all intact on the duplicate.
Every branch
Not just the default branch. Every branch on the source repository exists on the duplicate, exactly as it was at sync time.
Every tag and note
Tags and commit notes copy across too, so releases stay identifiable on the duplicate instead of turning into anonymous commits.
Git LFS is the one exception: pointer files copy across, the LFS object content does not.
Doing it yourself
Two Git commands get you a one-time copy. Here's exactly what they are, and what they don't give you.
git clone --mirror [email protected]:acme/api.git # bare clone, every ref
cd api.git
git remote set-url --push origin [email protected]:acme/api.git
git push --mirror # push every ref to the new homeThat's the easy part
Two commands copy a repository once. The hard part is everything after — running them again next week, and the week after that, for every repository that matters.
What you now own
Re-running the pair on every change, storing the SSH key or token somewhere safe, noticing when a push silently fails, deciding how many old copies to keep, and doing all of it again for the next repository.
Moving between hosts, orgs and accounts
The same four steps whether you're switching providers, consolidating orgs, or moving to a personal account.
Connect both ends
Authorize the source account and the destination account — OAuth for GitHub, GitLab and Bitbucket, a token or SSH key for a self-hosted server.
Create the binding
Pick the source repository and the destination. GitReplica creates the destination repository automatically on providers that support it; on a custom Git server, create it there first.
Run the first sync and verify
Trigger the sync and compare branch and tag counts against the source in the sync log before you rely on the copy.
Keep it or stop it
Leave the binding active for a standing duplicate that tracks the original, or deactivate it once the migration is confirmed and the old host is retired.
What a Git copy can't include
Some things live next to the repository, not inside it — no clone, mirror or push touches them.
Issues, pull requests and reviews
They live in the provider's database, not inside the Git repository, so no Git operation — mirror, clone or push — can carry them across. An object-storage archive can optionally capture them as a JSON snapshot; see Git backup archives.
CI configuration, secrets and settings
Workflow files travel with the repository since they're just tracked files. Secrets, self-hosted runners, branch protection rules and webhook configuration live in the provider's settings, not in Git — set those up again on the new host.
Duplication questions
How do I copy a Git repository with all its branches?
Run git clone --mirror against the source, then git push --mirror to the new remote — that copies every branch, tag and ref in two commands. GitReplica automates the same operation: connect both accounts, create a binding, and the first sync runs immediately.
Does duplicating include commit history?
Yes. The complete commit graph copies across — every commit, its author, message and parent links — not a squashed snapshot of the current state. Every branch, tag and note comes with it.
Can I keep the duplicate in sync automatically?
Yes. Leave the binding active and it behaves like any other GitReplica binding: GitHub, GitLab and Bitbucket sources sync the moment you push, and self-hosted or custom sources sync on a schedule — hourly, daily or weekly — or on demand.
Are issues and pull requests duplicated too?
No. Issues, pull requests and reviews live in the provider's database, not in the Git repository itself, so copying the repository — by hand or through a binding — never includes them. They can optionally be captured as a JSON snapshot in an object-storage archive.
Keep reading
Git repository mirroring
Mirror between GitHub, GitLab, Bitbucket and self-hosted, in any direction.
Back up a Git repository
Why a clone isn't a backup, and the four ways teams actually do it.
Git backup archives
What's inside an archive, how retention works, and how to restore.
git push --mirror explained
What it copies, force-updates and deletes — and how to verify before running it.
Git archive examples
Practical ZIP, TAR, folder, tag, prefix, and export-ignore examples.
Bitbucket mirroring & backup
Mirror Bitbucket repositories to GitHub, GitLab, self-hosted Git, or your own storage.
Duplicate a repository in two minutes.
Connect both ends, create a binding, and the first sync runs immediately. Free for open source and private non-commercial use.
Get started free