- Quando é necessária uma migração?
- O que deve ter em conta durante a mudança
- Criar um novo projeto no servidor de destino
- GitLab
- GitHub
- Transferir o repositório Git para o novo servidor Git
- 1. Verificar se existe um remote origin antigo
- 2. Definir o URL remoto para o novo projeto
- 3. Transferir todos os branches locais
- 4. Transferir as tags
- Tabela: diferenças entre os principais comandos git push
- Migração para GitLab ou GitHub
- Diferenças entre GitHub e GitLab
- Visão geral das principais diferenças
- Qual é o sistema mais adequado para cada utilização?
- Diferenças durante a migração
- Recomendações e boas práticas
- FAQ
- É possível transferir issues, merge requests ou conteúdos da wiki?
- O que acontece se o projeto de destino já contiver ficheiros?
- O que acontece aos branches antigos que existiam no servidor, mas não localmente?
- É necessário mudar o nome do branch master para main?
Ao transferir um repositório Git existente para um novo servidor Git, é comum surgirem dúvidas sobre o funcionamento técnico da migração e os cuidados necessários. Isto é especialmente importante quando o servidor antigo já não está disponível ou acessível, por exemplo ao mudar de um servidor GitLab autoalojado para o GitLab.com ou GitHub.
Neste artigo, explico passo a passo como funciona a migração, quais os comandos Git relevantes e em que situações o procedimento é diferente. Também abordo problemas comuns, alternativas e respostas a perguntas frequentes.
Quando é necessária uma migração?
Cenários comuns:
- O servidor Git antigo já não está acessível.
- Resta apenas um repositório local no computador ou servidor.
- O servidor antigo já não lhe pertence, por exemplo após mudar de empresa.
- Um projeto deve ser transferido de forma centralizada para o GitLab.com ou GitHub.
- Pretende consolidar vários repositórios.
Nestes casos, é importante saber se ainda possui todos os dados antigos ou apenas uma cópia local correspondente à última clonagem.
O que deve ter em conta durante a mudança
Antes de migrar um repositório Git, verifique os seguintes pontos:
- Ainda tem acesso ao servidor antigo?
Se sim, pode utilizargit push --mirrore transferir realmente tudo. - Tem apenas uma cópia local?
Nesse caso, só pode transferir os branches e as tags existentes localmente. - Foram utilizados merge requests, issues, wikis ou pipelines?
Estes dados não fazem parte do repositório e não podem ser transferidos através do Git. - O GitLab e o GitHub transferem apenas dados Git através de git push, keine Server-Metadaten.
Criar um novo projeto no servidor de destino
Independentemente de utilizar GitLab ou GitHub, comece por criar um novo projeto vazio.
GitLab
- Abrir o grupo
- « New project »
- « Create blank project »
- Desative « Initialize repository with a README » para efetuar a migração
(caso contrário, ocorrerá um conflito durante o push)
GitHub
- Repositories
- « New »
- Selecionar « Repository name »
- Não criar README nem .gitignore
- Criar o repositório
Transferir o repositório Git para o novo servidor Git
1. Verificar se existe um remote origin antigo
git remote -v
2. Definir o URL remoto para o novo projeto
git remote set-url origin <NEUE-URL>
Exemplo para GitLab:
https://gitlab.com/benutzer/projekt.git
Exemplo para GitHub:
https://github.com/benutzer/projekt.git
3. Transferir todos os branches locais
Se o servidor antigo já não estiver acessível:
git push -u origin --all #alternativ kann auch git push --mirror origin verwendet werden
Este comando transfere:
- todos os branches locais
- incluindo master ou main
- e configura o acompanhamento para futuros pushs
4. Transferir as tags
Se o projeto utilizava tags:
git push origin --tags
Tabela: diferenças entre os principais comandos git push
| Comando | Função | Recomendação |
|---|---|---|
git push --mirror origin | Copia todos os branches, tags, definições remotas e referências | Utilizar apenas se o servidor antigo ainda estiver acessível |
git push -u origin --all | Transfere todos os branches locais | Método padrão para migrar sem o servidor antigo |
git push origin --tags | Transfere todas as tags | Executar depois do push dos branches |
git push -f origin | Força a substituição do branch de destino | Apenas em caso de conflito com um repositório de destino vazio |
git remote set-url origin <URL> | Altera o endereço remoto | Passo principal da migração |
Migração para GitLab ou GitHub
| Tema | GitLab | GitHub |
|---|---|---|
| Iniciar o projeto sem README | Possível | Possível |
| Funções de importação na interface web | Muito abrangentes | Abrangentes, mas menos do que no GitLab |
| Transferência de issues | Não, exceto através de API ou exportações | Não |
| Comandos push idênticos | Sim | Sim |
| Migração LFS | Suportada | Suportada |
Na prática, não existem grandes diferenças, pois ambas as plataformas suportam Git de forma nativa. A migração utiliza os mesmos comandos em ambas.
Diferenças entre GitHub e GitLab
Embora GitHub e GitLab pareçam muito semelhantes e ambos funcionem perfeitamente como servidores Git, existem diferenças relevantes ao migrar um repositório ou trabalhar a longo prazo. Muitos principiantes perguntam-se se a mudança para GitHub funciona de forma diferente da mudança para GitLab ou se faltam determinadas funções. A boa notícia é que os comandos Git são idênticos em ambas as plataformas, apesar de estas diferirem claramente em algumas áreas.
Visão geral das principais diferenças
| Área | GitHub | GitLab |
|---|---|---|
| Foco | A maior plataforma de desenvolvimento do mundo, fortemente orientada para a comunidade | Plataforma DevOps com CI/CD e gestão de projetos integrados |
| Repositórios privados | Gratuitos, mas com funcionalidades limitadas | Gratuitos e com muitas funcionalidades, também para equipas |
| CI/CD | GitHub Actions, muito flexível | GitLab CI/CD integrado nativamente |
| Estrutura de projetos | Estrutura plana, centrada nos repositórios | Estrutura robusta de grupos e subgrupos |
| Gestão de issues | Simples e clara | Mais abrangente, com quadros, epics e roadmaps |
| Wikis | Por repositório | Por projeto, com mais funções de gestão |
| Ferramentas de importação | Boas, mas menos abrangentes do que as do GitLab | Funções de importação muito abrangentes para GitHub, Bitbucket, Jira, etc. |
| Alojamento próprio | GitHub Enterprise, dispendioso | O GitLab pode ser totalmente autoalojado; a Community Edition é gratuita |
| Gestão de permissões | Simples | Muito granular e baseada em funções |
| Armazenamento gratuito | Limitado para LFS | Mais espaço gratuito para repositórios e o registo de contentores |
Qual é o sistema mais adequado para cada utilização?
O GitHub é ideal se:
- está a iniciar um projeto de código aberto
- pretende envolver muitos programadores externos
- procura uma grande comunidade e muitas integrações prontas a utilizar
- pretende utilizar GitHub Actions
O GitLab é ideal se:
- procura uma solução DevOps completa
- pretende organizar muitos projetos em grupos
- necessita de alojamento próprio ou controlo total
- pretende utilizar CI/CD sem ferramentas adicionais
Diferenças durante a migração
Para a migração propriamente dita de um repositório Git, pouco importa utilizar GitHub ou GitLab, pois ambos suportam os mesmos padrões Git. As diferenças estão sobretudo no ambiente:
- O GitHub cria automaticamente o branch main, O GitLab só o faz opcionalmente.
- Depois do push, o GitLab apresenta automaticamente indicações para criar merge requests.
- O GitHub dá mais importância a pull requests do que a merge requests.
- O GitLab suporta repositórios espelho nativamente; o GitHub requer automatização ou Actions.
- O GitLab oferece assistentes de importação abrangentes para transferir projetos GitHub com as respetivas issues.
Recomendações e boas práticas
- Projeto público ou privado? Defina-o antecipadamente no projeto de destino.
- Chave SSH ou HTTPS? O SSH evita a introdução constante de palavras-passe.
- Verifique os branches locais antes de os enviar.
- Elimine previamente os branches antigos que já não são necessários.
- Depois do push, confirme se todos os branches e tags foram transferidos corretamente.
FAQ
É possível transferir issues, merge requests ou conteúdos da wiki?
Não. Estes dados encontram-se no servidor e não no repositório Git. Só podem ser migrados através de exportações ou API.
O que acontece se o projeto de destino já contiver ficheiros?
Ocorrerão conflitos. É preferível criar o projeto de destino completamente vazio.
O que acontece aos branches antigos que existiam no servidor, mas não localmente?
Serão perdidos se já não tiver acesso ao servidor antigo.
É necessário mudar o nome do branch master para main?
Não. O GitLab e o GitHub aceitam ambos os nomes.
Este artigo foi traduzido com a ajuda de IA.