Bring your code over
Gitza’s built-in migration pulls a repository straight from GitHub, GitLab or Bitbucket, and with it the issues, pull requests, labels and milestones that give the history its context. Nothing is installed on your side; you give Gitza the address and a token that can read the source, and it does the rest.
You migrate one repository at a time, from the + menu → New Migration.
Get a token from the source
Public repositories need no token for the code alone. Everything else does: private repositories, and issues and pull requests on any repository, are read through the source’s API, which needs to know who is asking.
GitHub
Create a personal access token under Settings → Developer settings. A fine-grained token
needs read access to Contents, Issues, Pull requests and Metadata on the
repositories you are moving; a classic token needs the repo scope. Set it to expire; you will
not need it once the migration is done.
Start the migration
Open + → New Migration and choose the source. Then:
- Paste the repository’s clone address (the HTTPS one).
- Enter the token from the previous step. For a private repository this is required; for a public one it is what lets Gitza read the issues and pull requests.
- Tick what to bring: Issues, Pull Requests, Labels, Milestones, and where the source offers them, Releases and the Wiki.
- Choose the owner (you or an organisation), the name and the visibility on Gitza. A private repository at the source is private here by default.
- Click Migrate Repository.
A small repository finishes in seconds. A large one with years of issues can take a while, because the source’s API is rate-limited; the page shows progress and the repository becomes usable when it is done.
Check the result
Open the new repository and compare the numbers with the source: branches, tags, open and closed issues, pull requests. Comments come across with their original author’s name and date; the accounts they belonged to on the other service are not on Gitza, so they are recorded as text rather than linked to a user.
Migration copies. The source repository is untouched, and you can run it again with a different name if something was not right. Delete the copy you do not want from its Settings.
What migration does not carry
- Collaborators and permissions. Add people again under the repository’s or the organisation’s settings.
- Webhooks, deploy keys and secrets. These name other systems and should be created fresh, pointing at Gitza.
- Branch protection rules. Recreate them under Settings → Branches.
- Pipelines. Gitza does not run CI at launch; see CI/CD.
After you migrate is the checklist for all of these.