Linux Kamarada
Cadê o anúncio que estava aqui?
Parece que você está usando um bloqueador de anúncios. Mas dependemos deles para continuar criando conteúdo gratuito e de qualidade para você. Se você gosta do nosso conteúdo, por favor apoie nosso site desativando seu bloqueador de anúncios. Alternativamente, se você vem aqui com frequência, por favor considere fazer uma doação.
O texto de hoje é para os desenvolvedores e projetistas de software livre. Se você acompanha meu trabalho, provavelmente já sabe que o Linux Kamarada está migrando para o GitLab. Se você também pensa em migrar seus repositórios de código-fonte do GitHub para o GitLab, preparei o passo a passo a seguir mostrando como você pode fazer isso.
Esse tutorial segue a ideia de compartilhar os bastidores do Linux Kamarada. Sendo assim, como exemplo, mostrarei como migrei o repositório Linux-Kamarada-GNOME, que contém a appliance do Kiwi usada para gerar a imagem ISO da distribuição.
Como funciona
Você pode importar seus repositórios do GitHub para o GitLab.com ou para seu próprio servidor do GitLab (self-hosted).
Praticamente tudo dos projetos é importado, como: descrição, dados do Git (commits, branches, tags, etc), issues e pull requests (e seus comentários), páginas da wiki e mais.
Observe que o que o GitHub chama de pull requests, o GitLab chama de merge requests.
Referências a issues e pull requests são preservadas. Ao importar issues e pull requests, o importador tenta encontrar seus autores e assignees (designados) do GitHub no GitLab. Para que essa associação funcione, cada autor e assignee no repositório do GitHub deve atender a uma das seguintes condições antes da importação:
- Ter feito login anteriormente em uma conta do GitLab usando o ícone do GitHub.
- Ter uma conta no GitHub com um endereço de e-mail visível ao público que corresponda ao endereço de e-mail da sua conta no GitLab.
Se um usuário referenciado em uma issue não for encontrado no GitLab, o criador do projeto (normalmente o usuário que iniciou o processo de importação) é referenciado em seu lugar, mas uma observação é adicionada à issue informando o usuário original no GitHub.
Se quiser mais detalhes sobre o processo, consulte a documentação do GitLab.
Agora, vamos ver como migrar projetos do GitHub para o GitLab na prática!
Importando o repositório para o GitLab
Entre (faça login) na sua conta do GitLab.
Em seguida, na barra de navegação ao topo, vá em Menu > Projects (projetos) > Create new project (criar novo projeto):
Na tela seguinte, escolha Import project/repository (importar projeto/repositório):
E então, clique no GitHub:
Você será redirecionado para uma página no GitHub para autorizar o GitLab. Faça login na sua conta do GitHub:
Você será redirecionado de volta para o GitLab, que listará todos os seus repositórios do GitHub.
Procure na lista o repositório que você quer importar (ex.: Linux-Kamarada-GNOME):
Selecione para qual grupo ou usuário o repositório será importado (ex.: o grupo kamarada, em vez da minha conta de usuário antoniomedeiros):
Você também pode mudar o nome do repositório, se quiser (é opcional).
Quando terminar, clique no botão Import (importar) na mesma linha do repositório.
A coluna Status mostra o status da importação de cada repositório. Você pode deixar a página aberta que ela se atualiza sozinha ou pode navegar normalmente, fazer outras coisas e voltar para ela depois.
Concluída a importação do repositório, você pode clicar no botão Go to project (ir para o projeto):
Confira se está tudo no lugar. Por exemplo, os branches (ramificações) foram importados:
As issues tanto abertas (open) quanto fechadas (closed) também foram importadas:
Note que a importação do GitLab traduziu corretamente meu usuário vinyanalista do GitHub para meu usuário antoniomedeiros do GitLab, mas não encontrou equivalente no GitLab para o usuário kevinsmia1939 do GitHub, importando os comentários dele com a minha conta e adicionando observações no início para esclarecer que são, na verdade, dele:
Talvez ele não tenha conta no GitLab ou, se tem, se registrou com outro e-mail.
Atualizando o remote do clone local
Agora que seu repositório está no GitLab, se você tem um clone dele no seu computador, deve apontar sua cópia local para o novo repositório remoto.
Para isso, abra um terminal na pasta do repositório local.
Liste os repositórios remotos configurados:
1
2
3
$ git remote -v
origin git@github.com:kamarada/Linux-Kamarada-GNOME.git (fetch)
origin git@github.com:kamarada/Linux-Kamarada-GNOME.git (push)
O remoto padrão origin está apontando para o GitHub. Vamos apontá-lo para o GitLab.
Abra o projeto importado no GitLab e copie sua URL como se fosse cloná-lo:
De volta ao terminal, mude a URL do remoto origin:
1
$ git remote set-url origin git@gitlab.com:kamarada/Linux-Kamarada-GNOME.git
Se você listar os remotos de novo, verá que agora o padrão origin aponta para o GitLab:
1
2
3
$ git remote -v
origin git@gitlab.com:kamarada/Linux-Kamarada-GNOME.git (fetch)
origin git@gitlab.com:kamarada/Linux-Kamarada-GNOME.git (push)
De agora em diante, todo git pull e git push irá baixar e enviar commits para o GitLab.
Opcionalmente, se você ainda vai precisar fazer alterações no repositório que está no GitHub (como, por exemplo, eu precisei alterar arquivos no kamarada-website que está no GitHub, que divergiu do equivalente kamarada.gitlab.io no GitLab), você pode adicionar a URL do antigo repositório no GitHub como um novo remoto, com outro nome (ex.: github):
1
2
3
4
5
6
7
$ git remote add github git@github.com:kamarada/Linux-Kamarada-GNOME.git
$ git remote -v
github git@github.com:kamarada/Linux-Kamarada-GNOME.git (fetch)
github git@github.com:kamarada/Linux-Kamarada-GNOME.git (push)
origin git@gitlab.com:kamarada/Linux-Kamarada-GNOME.git (fetch)
origin git@gitlab.com:kamarada/Linux-Kamarada-GNOME.git (push)
Com isso, você pode fazer alterações nos dois repositórios sem precisar fazer outro clone (aqui, não vou entrar em detalhes de como gerenciar esse arranjo).
Avisando a todos a mudança
É recomendado encerrar todas as issues e pull requests no GitHub, assim como atualizar o arquivo README (leia-me) e a descrição do repositório, informando a todos que o repositório mudou de endereço para o GitLab. Talvez você queira avisar às pessoas também nas redes sociais, no site do projeto, etc.
Como exemplo, veja como ficou o repositório Linux-Kamarada-GNOME após os avisos e o arquivamento (falarei sobre isso na sequência):
Arquivo README e descrição do repositório
Comentário na issue, tornada somente leitura pelo arquivamento
Na verdade, eu não fechei as issues: as que estavam abertas, deixei abertas, apenas fiz comentários com links para o novo endereço no GitLab (a numeração é mantida). Como eu tinha poucas issues abertas, saí comentando em cada uma (mas fiz isso só nas abertas). Se você souber alguma forma de automatizar esses comentários — pro caso de um repositório com muitas issues abertas — por favor, compartilhe comigo nos comentários.
Arquivando o repositório do GitHub
Se você não vai mais fazer alterações no repositório antigo no GitHub, você pode arquivá-lo a fim de torná-lo somente leitura e indicar que não recebe mais manutenção. Caso você mude de ideia no futuro, o GitHub permite desarquivar repositórios que foram arquivados.
Para arquivar o repositório no GitHub, acesse a página principal do repositório.
Abaixo do nome do repositório, clique em Settings (configurações):
Em Danger Zone (zona de perigo), clique em Archive this repository (arquivar este repositório):
Leia os avisos com atenção:
Depois, digite o nome do repositório que você deseja arquivar e clique em I understand the consequences, archive this repository (entendo as consequências, arquive este repositório).
Conclusão
Pronto! Agora você pode conferir o novo repositório no GitLab: Linux-Kamarada-GNOME. E o repositório antigo arquivado no GitHub: Linux-Kamarada-GNOME.
Durante os próximos dias estarei migrando mais repositórios usando esse meu próprio roteiro. Espero que ele possa ser útil para você também.
Referências
