Comes over
The complete Git history, every branch, every tag, submodule pointers, and your .github/workflows files — because it is a Git push.
Migrate
Run it beside your current host
Four steps, all of them ordinary Git after the first command. Keep both remotes for a week or a quarter, and cut over when the team is ready — or never.
All four steps, commands only
01
Create the repository and add a second remote
gbb repo create adds a remote named gbb beside origin. Nothing about origin, your branches, or their upstreams changes.
$ gbb repo create acme/checkout-api --private --source . --remote gbb
created repository acme/checkout-api at https://gbb.example/acme/checkout-api
added remote gbb -> https://gbb.example/acme/checkout-api; origin was not changed
02
Mirror every branch and tag
Plain git. Full history, all branches, all tags — and because this is a push, not a set-upstream, your local branches keep tracking origin.
$ git push gbb --all
$ git push gbb --tags
* [new branch] main -> main
* [new tag] v1.9.3 -> v1.9.3
03
Run both for as long as you like
Push to both remotes while the team gets used to reviewing here. Actions is planned for launch: workflows in .github/workflows will run here on push. Until then, other CI can keep reporting check runs through the API or gbb.
$ git push origin main && git push gbb main
Everything up-to-date
04
Cut over
When you are ready, swap the remote names. Existing clones keep working against old-origin until each person repeats the two renames.
$ git remote rename origin old-origin
$ git remote rename gbb origin
Stays where it was
Issues, pull requests, and CI secrets and settings. There is no importer; those start fresh here.
To undo
git remote remove gbb. Nothing else on your machine or in the old host was touched.
Wondering about limits on repository size or pack objects? See technical limits.
Two remotes, no ceremony
Create an account, run the first command, and your repository is here — with the old one exactly where it was.