Tipos de migrações
Você pode fazer três tipos de migração:
- Migração de uma instância do GitHub Enterprise Server para outra existente do GitHub Enterprise Server. você pode migrar qualquer número de repositórios pertencentes a qualquer usuário ou organização na instância. Para executar a migração, você deve ter acesso de administrador do site a ambas as instâncias.
- Migração de uma organização do GitHub.com para uma instância do GitHub Enterprise Server: você pode migrar qualquer número de repositórios pertencentes à organização. Antes de executar uma migração, você precisa ter acesso administrativo na organização do GitHub.com e acesso de administrador do site na instância de destino.
- As execuções de avaliação são migrações que importam dados para uma instância de preparo. Elas podem ser úteis para ver o que aconteceria se uma migração fosse aplicada ao GitHub.com. Recomendamos fortemente que você execute uma execução de avaliação em uma instância de preparo antes de importar dados para sua instância de produção.
Observação: o uso do ghe-migrator não é recomendado para transferir uma instância do GitHub Enterprise Server entre hipervisores. Em vez disso, sugerimos fazer backup e restaurar para o novo local com GitHub Enterprise Server Backup Utilities ou criar uma réplica no novo local e, em seguida, fazer failover para o dispositivo de réplica. Para saber mais, confira "Como configurar backups em sua instância", "Criar réplica de alta disponibilidade" e "Iniciar failover do appliance réplica".
Dados migrados
Com o ghe-migrator, tudo gira em torno de um repositório. A maioria dos dados associados ao repositório pode ser migrada. Por exemplo, um repositório em uma organização migrará o repositório e a organização, bem como todos os usuários, as equipes, os problemas e as solicitações de pull associadas ao repositório.
Os itens na tabela abaixo podem ser migrados com um repositório. Os itens não mostrados na lista de dados migrados não podem ser migrados, incluindo os ativos do Git LFS.
Observação: as relações de fork não são persistentes após uma migração.
| Dados associados a um repositório migrado | Observações |
|---|---|
| Usuários | As @mentions aos usuários são rescritas para corresponderem ao destino. |
| Organizações | Os nomes e detalhes das organizações são migrados. |
| Repositórios | Links para árvores, blobs, commits e linhas do Git são rescritas para corresponder ao destino. Repositórios internos são migrados como repositórios privados. O status de arquivo morto não está definido. |
| Wikis | Todos os dados da wiki são migrados. |
| Teams | As @mentions às equipes são rescritas para corresponderem ao destino. |
| Marcos | Os registros de data e hora são preservados. |
| Quadros de Projects (classic) | Os Projetos (clássicos) associados ao repositório e à organização proprietária do repositório são migrados. Projects, a experiência de projetos completamente nova, agora está disponível. |
| Problemas | As referências a problemas e os registros de data e hora são preservados. |
| Comentários dos problemas | As referências cruzadas aos comentários são rescritas para a instância de destino. |
| Solicitações de pull | As referências cruzadas a pull requests são rescritas para corresponder ao destino. Os registros de data e hora são preservados. |
| Revisões de pull request | As revisões de pull request e os dados associados são migrados. |
| Comentários das revisões de pull request | As referências cruzadas aos comentários são rescritas para a instância de destino. Os registros de data e hora são preservados. Os comentários no nível do arquivo não são migrados. |
| Comentários de commit | As referências cruzadas aos comentários são rescritas para a instância de destino. Os registros de data e hora são preservados. |
| Versões | Todos os dados das versões são migrados. |
| Ações feitas em problemas ou em pull requests | São preservadas todas as modificações em problemas ou pull requests, como atribuir usuários, renomear títulos e modificar etiquetas, bem como os registros de data e hora de cada ação. |
| Anexos de arquivo | Os anexos de arquivo em problemas e solicitações de pull são migrados. Você pode desabilitar essa opção como parte da migração. |
| Webhooks | Somente os webhooks ativos são migrados. |
| Chaves de implantação de repositório | As chaves de implantação de repositório são migradas. |
| Branches protegidos | As configurações de branches protegidos e os dados associados são migrados. |
Sobre migração de dados de autenticação externa
Se a origem da migração for um produto do GitHub que usa autenticação LDAP ou SAML, o ghe-migrator não migrará os dados de autenticação externa vinculados a contas de usuário. Para obter mais informações sobre as opções de autenticação, veja GitHub Enterprise Server, veja "Sobre autenticação para a sua empresa" nos documentos do GitHub Enterprise Server" ou nos documentos do GitHub Enterprise Cloud.
Se você migrar para uma instância de destino e depois configurar a autenticação externa, os usuários deverão entrar na instância de destino com uma conta de usuário que tenha o mesmo nome de usuário ou ID de usuário que a conta na instância de origem. Os administradores podem revisar o atributo externo que uma instância usa para mapear nomes de contas de usuário no GitHub. Para obter mais informações, confira "Acessar o Console de Gerenciamento".