Sobre migrações entre produtos GitHub

Sobre as migrações entre produtos do GitHub

Com o GitHub Enterprise Importer, você pode migrar dados do GitHub Enterprise Server para o GitHub Enterprise Cloud ou migrar dados do GitHub.com para outra conta no GitHub Enterprise Cloud.

Por exemplo, o GitHub Enterprise Importer pode ajudar sua empresa a:

• Adotar o GitHub Enterprise Cloud com residência de dados migrando sua empresa para o GHE.com
• Adotar alguns recursos no GitHub.com, como os Enterprise Managed Users ou os novos modelos de cobrança, migrando entre empresas no GitHub.com
• Aproveitar a administração simplificada e novos recursos migrando do GitHub Enterprise Server para o GitHub Enterprise Cloud

Se a origem de migração for uma conta no GitHub.com, você poderá migrar repositórios individuais entre organizações ou migrar organizações inteiras entre empresas. Se a origem de migração for o GitHub Enterprise Server, você poderá migrar repositórios individuais.

Os dados migrados por GitHub Enterprise Importer dependem da origem da migração e se você está migrando um repositório ou organização.

Considerações sobre migrações para o GitHub Enterprise Cloud

Para usar o GitHub Enterprise Importer, esteja ciente das seguintes considerações:

• Se você já usa o GitHub Enterprise Cloud: um plano do GitHub Enterprise dá a você direito a uma implantação do GitHub Enterprise Cloud.

  Por exemplo, se você já usar o GitHub.com e também quiser migrar do GitHub Enterprise Server para o GHE.com, seu uso para os dois não será coberto em um só plano.

• Se você estiver migrando para os Enterprise Managed Users: você precisará se integrar a um provedor de identidade para gerenciar as contas de usuário. Verifique o nível de suporte para seu provedor de identidade antes de começar. Confira Sobre os Enterprise Managed Users.

• Se você estiver migrando do GitHub Enterprise Server: lembre-se de que o GitHub aplica limites de taxa a determinadas ações, que estão desabilitadas por padrão no GitHub Enterprise Server. Confira Limites de taxa para a API REST.

• Se você estiver migrando para o GitHub Enterprise Cloud com residência de dados: lembre-se de que determinados recursos não estão disponíveis e alguns recursos exigem uma configuração diferente ou adicional. Confira Visão geral de recursos do GitHub Enterprise Cloud com residência de dados.

Dados migrados do GitHub Enterprise Server

git clone --mirror OLD-REPOSITORY-URL
cd OLD-REPOSITORY-NAME
git remote add new-origin NEW-REPOSITORY-URL
git push new-origin --mirror

git clone --mirror OLD-REPOSITORY-URL
cd OLD-REPOSITORY-NAME
git remote add new-origin NEW-REPOSITORY-URL
git push new-origin --mirror

Para migrar do GitHub Enterprise Server (GHES), você precisa ter o GHES versão 3.4.1 ou superior. Os dados migrados dependem da versão que está sendo usada.

Diferentes limites de tamanho por repositório se aplicam dependendo da versão do GHES.

Dados que não são migrados

Atualmente, os dados a seguir não são migrados.

• Logs de auditoria
• Resultados do Code scanning
• Verificações de status de commit
• Alertas do Dependabot
• Segredos do Dependabot
• Discussões no nível do repositório
• Editar o histórico de comentários de problemas e de solicitação de pull
• Relações de fork entre repositórios (confira "Sobre bifurcações")
• Segredos, variáveis, ambientes, executores auto-hospedados, executor maiors ou histórico de execução do fluxo de trabalho do GitHub Actions
• Instalações do Aplicativo GitHub e Aplicativos do GitHub
• Os objetos e os binários grandes do Git LFS (ainda há suporte para os repositórios que usam o Git LFS. Confira "Limitações do GitHub Enterprise Importer")
• Pacotes do GitHub Packages
• Projetos (clássicos) no nível da organização
• Projects (a nova experiência de projetos)
• Referências entre solicitações de pull e problemas em repositórios diferentes (confira "URLs e referências autovinculadas")
• Estados de correção dos resultados da secret scanning
• Repositórios pertencentes a contas de usuário
• Propriedades do repositório
• Estrelas do repositório
• Observadores do repositório
• Conjuntos de regras
• Regras de proteção para tags
• Perfis de usuários, chaves SSH, chaves de assinatura ou personal access tokens
• Segredos do Webhook
• Teams
• Acesso de usuário ou de equipe ao repositório
• Configurações do repositório para solicitações de pull

Proteções de ramificação

As proteções de branch aplicam um conjunto especificado de regras a um nome de branch específico ou a um padrão de nome de branch. Para obter mais informações, confira "Sobre branches protegidos".

As proteções de branch sempre serão migradas, mas algumas regras não serão migradas. As regras de proteção de branch a seguir não são migradas.

• Permitir que atores específicos ignorem as solicitações de pull necessárias
• Exigir a aprovação do push mais recente
• Exigir que as implantações tenham êxito antes da mesclagem
• Bloquear branch
• Restringir os pushes que criam branches correspondentes
• Permitir push forçado

As seguintes limitações também se aplicam:

• Se uma regra de proteção de branch opcionalmente permitir que você especifique pessoas, equipes ou aplicativos que são isentos da regra, como "Restringir quem pode ignorar revisões de solicitação de pull", as exceções não serão migradas.
• Se a regra "Permitir pushes forçados" estiver habilitada no modo "Especificar quem pode forçar o push", a regra não será migrada.

Dados migrados do GitHub.com

Se a origem de migração for uma conta no GitHub.com, você poderá migrar repositórios individuais entre organizações ou migrar organizações inteiras entre empresas.

Dados migrados para uma organização

Quando você migra uma organização, uma organização é criada na conta corporativa de destino. Em seguida, os dados a seguir são migrados para a nova organização.

• Teams
• Repositórios
• Acesso de equipe aos repositórios
• Privilégios de membro
• Webhooks no nível da organização (devem ser reabilitados após a migração, confira Como habilitando webhooks)
• Nome do branch padrão para os repositórios criados na organização

Todos os repositórios são migrados com visibilidade particular. Caso você deseje definir a visibilidade de um repositório como pública ou interna, faça isso após a migração usando a interface do usuário ou a API.

A associação à equipe não é migrada. Após a migração, você precisará adicionar membros às equipes migradas. Para saber mais, confira Visão geral de uma migração entre produtos GitHub.

Dados migrados para um repositório

Quando você migra um repositório, diretamente ou como parte de uma migração da organização, apenas os dados a seguir são migrados.

• Origem do Git (incluindo o histórico de commits)
• Solicitações de pull
• Problemas
• Marcos
• Wikis (excluindo anexos)
• Fluxos de trabalho GitHub Actions
• Comentários de commit
• Webhooks ativos (devem ser reabilitados após a migração, confira Como habilitar webhooks)
• Tópicos do repositório
• Configurações do repositório
  • Proteções de branch (confira Proteções de branch para obter mais detalhes)
  • Configurações do GitHub Pages
  • Referência de link automático
  • Configurações do GitHub Advanced Security
  • Configurações de solicitação de pull
    • Excluir branches de cabeçalho automaticamente
    • Permitir mesclagem automática
    • Permitir commits de mesclagem (a configuração da mensagem de commit é redefinida para a mensagem padrão)
    • Permitir mesclagem squash (a configuração da mensagem de commit é redefinida para a mensagem padrão)
    • Permitir mesclagem de troca de base
• Versões (até 10 GB por repositório)
• Histórico do usuário para os dados acima
• Anexos (confira Anexando arquivos)

Dados que não são migrados

Atualmente, os dados a seguir não são migrados.

• Codespaces secrets * Logs de auditoria
• Resultados do Code scanning
• Verificações de status de commit
• Alertas do Dependabot
• Segredos do Dependabot
• Discussões no nível do repositório
• Editar o histórico de comentários de problemas e de solicitação de pull
• Relações de fork entre repositórios (confira "Sobre bifurcações")
• Segredos, variáveis, ambientes, executores auto-hospedados, executor maiors ou histórico de execução do fluxo de trabalho do GitHub Actions
• Instalações do Aplicativo GitHub e Aplicativos do GitHub
• Os objetos e os binários grandes do Git LFS (ainda há suporte para os repositórios que usam o Git LFS. Confira "Limitações do GitHub Enterprise Importer")
• Pacotes do GitHub Packages
• Projetos (clássicos) no nível da organização
• Projects (a nova experiência de projetos)
• Referências entre solicitações de pull e problemas em repositórios diferentes (confira "URLs e referências autovinculadas")
• Estados de correção dos resultados da secret scanning
• Repositórios pertencentes a contas de usuário
• Propriedades do repositório
• Estrelas do repositório
• Observadores do repositório
• Conjuntos de regras
• Regras de proteção para tags
• Perfis de usuários, chaves SSH, chaves de assinatura ou personal access tokens
• Segredos do Webhook
• Acesso do usuário ao repositório

Quando você migra um repositório diretamente, as equipes e o acesso de equipe aos repositórios não são migrados.

Proteções de ramificação

As proteções de branch aplicam um conjunto especificado de regras a um nome de branch específico ou a um padrão de nome de branch. Para obter mais informações, confira "Sobre branches protegidos".

As proteções de branch sempre serão migradas, mas algumas regras não serão migradas. As regras de proteção de branch a seguir não são migradas.

• Permitir que atores específicos ignorem as solicitações de pull necessárias
• Exigir a aprovação do push mais recente
• Exigir que as implantações tenham êxito antes da mesclagem
• Bloquear branch
• Restringir os pushes que criam branches correspondentes
• Permitir push forçado

As seguintes limitações também se aplicam:

• Se uma regra de proteção de branch opcionalmente permitir que você especifique pessoas, equipes ou aplicativos que são isentos da regra, como "Restringir quem pode ignorar revisões de solicitação de pull", as exceções não serão migradas.
• Se a regra "Permitir pushes forçados" estiver habilitada no modo "Especificar quem pode forçar o push", a regra não será migrada.

Limitações dos dados migrados

Há limites para o que o GitHub Enterprise Importer pode migrar. Alguns ocorrem devido a limitações do GitHub, enquanto outros são limitações do próprio GitHub Enterprise Importer.

Limitações do GitHub

• Limite de tamanho de 2 GB para um commit individual do Git: nenhum commit individual no repositório Git pode ter mais de 2 GB. Se um dos commits for maior que 2 GB, divida o commit em commits menores que tenham 2 GB ou menos cada.
• Limite de 255 bytes para referências do Git: nenhuma referência individual do Git, comumente conhecida como "referência", pode ter um nome maior que 255 bytes. Normalmente, isso significa que as referências não podem ter mais de 255 caracteres, mas qualquer caractere não ASCII, como emojis, pode consumir mais de um byte. Se uma das referências do Git for muito grande, retornaremos uma mensagem de erro clara.
• Limite de tamanho de 100 MB para arquivos: nenhum arquivo individual no repositório Git pode ter mais de 100 MB. Considere o uso do Git LFS para armazenar arquivos grandes. Para obter mais informações, confira "Gerenciar arquivos grandes".

Limitações do GitHub Enterprise Importer

• Limite de tamanho de 10 GB para um repositório Git: esse limite só se aplica ao código-fonte. Para verificar se o arquivo do repositório está acima do limite, use a ferramenta git-sizer e analise o tamanho total do BLOB na saída. A ferramenta git-sizer também ajuda a identificar possíveis problemas relacionados a arquivos grandes, tamanho de BLOB, tamanho de commit e contagens de árvores que podem afetar as migrações.
• Limite de 10 GB para metadados: o Importer não pode migrar repositórios com mais de 10 GB de metadados. Os metadados incluem problemas, solicitações de pull, versões e anexos. Na maioria dos casos, os metadados grandes são causados por ativos binários anexados a versões. Você pode excluir versões da migração com o sinalizador migrate-repo do comando --skip-releases e mover as versões manualmente após a migração.
• Os objetos do Git LFS não migrados: o Importer pode migrar repositórios que usam o Git LFS, mas os próprios objetos LFS não serão migrados. Eles podem ser enviados por push para o destino de migração como uma tarefa de acompanhamento após a conclusão da migração. Para obter mais informações, confira "Duplicar um repositório".
• Tarefas de acompanhamento necessárias: ao migrar entre produtos do GitHub, algumas configurações não são migradas e precisam ser reconfiguradas no novo repositório. Para ver uma lista de tarefas de acompanhamento que você precisará concluir após cada migração, confira "Visão geral de uma migração entre produtos GitHub".
• Funcionalidade de pesquisa de código atrasada: a reindexação do índice de pesquisa pode levar algumas horas após a migração de um repositório, e as pesquisas de código podem retornar resultados inesperados até que a reindexação seja concluída.
• Os conjuntos de regras configurados para sua organização podem causar falha nas migrações: por exemplo, se você tiver configurado uma regra que exige que os endereços de email dos autores de commits terminem com @monalisa.cat e o repositório que você está migrando contém commits que não obedecem a essa regra, sua migração falhará. Para saber mais sobre os conjuntos de regras, confira "Sobre os conjuntos de regras".
• O conteúdo do manequim pode não ser pesquisável: os manequins são usuários de espaço reservado aos quais o conteúdo importado (como problemas, solicitações de pull, comentários, etc.) está associado. Quando você pesquisa conteúdo associado a um manequim, como problemas atribuídos, os problemas podem não ser encontrados. Uma vez que um manequim é recuperado, o conteúdo deve ser encontrado por meio do novo proprietário. Para obter mais informações, confira "Como recuperar manequins no GitHub Enterprise Importer".

Introdução

Antes de migrar entre produtos GitHub, você deve planejar como executará a migração. Antes de migrar quaisquer dados, você precisará escolher alguém para executar a migração. Você deve conceder a essa pessoa o acesso necessário à origem e ao destino da migração. Também recomendamos executar uma migração de avaliação primeiro.

Para obter uma visão geral do processo de migração do início ao fim, confira Visão geral de uma migração entre produtos GitHub.