After you migrate

A migrated repository is a copy until your team and your tools point at it. Work through this list for each one.

Repoint every clone

On every machine that has the repository checked out:

git remote set-url origin git@git.gitza.co.za:you/your-repo.git
git fetch origin

Branches that were tracking the old remote keep working, because the remote name is the same and only its address changed. git remote -v confirms it.

Invite the people

Migration brings the code and its history, not the accounts. Add collaborators in the repository’s Settings → Collaborators, or, if the repository belongs to an organisation, put them in a team with access to it. Each person needs a Gitza account and their own SSH key.

Recreate what pointed elsewhere

• Branch protection: Settings → Branches. Require pull requests, reviews and a clean history on main exactly as before.
• Webhooks: Settings → Webhooks. Anything that listened to the old repository, from a chat notification to a deployment trigger, needs the new one.
• Deploy keys: Settings → Deploy Keys, for servers that pull read-only.
• Access tokens for tools: each tool that pushed or pulled over HTTPS needs a Gitza token.
• Badges and links: READMEs, wikis and internal docs that link to the old address.

Make the old one read-only, then archive it

Once the team has pushed to Gitza for a week or two without reaching for the old remote, archive the source repository on the other service. Archiving keeps it readable and stops anyone pushing to it by habit, which is the one thing that turns a clean migration into two diverging histories. Delete it when you are sure.

Fix authorship, if you need to

Commits carry the email address that made them. If your team used different addresses on the old service, a .mailmap file in the repository maps them to the names and addresses you want shown, without rewriting history.