Como fazer a migração de um projeto existente para o GitHub?

Concluído

Aqui abordamos considerações importantes para migrar um projeto para o GitHub de um sistema de controle de versão herdado.

Por que migrar para o GitHub?

Há volumes de literatura que estão exaltando as virtudes do GitHub. Está além do escopo deste módulo convencê-lo a se mover. Mas, podemos recapitular alguns dos principais benefícios dentro do contexto de tópicos que você precisa considerar ao planejar sua migração.

Controle de versão

O GitHub usa exclusivamente o Git, comprovadamente o melhor sistema de controle de versão disponível. No entanto, o Git é incrivelmente sofisticado e pode apresentar alguns cenários complexos para trabalhar com código com os quais sua equipe pode não ter experiência. Branches e solicitações de pull são uma parte fundamental do dia a dia dos desenvolvedores que usam o Git, portanto entender quando e como usá-los efetivamente é necessário para ter êxito no GitHub. Vale a pena que sua equipe primeiro esteja familiarizada com o fluxo do GitHub para que você possa partir para a ação.

Mantenha seu código na nuvem

Uma grande quantidade de código de projeto ainda é armazenada em sistemas de controle de versão herdados sob a proteção de firewalls corporativos. Ao migrar para o GitHub, você está movendo seu código para a plataforma de nuvem do GitHub, na qual os membros da equipe poderão acessá-lo facilmente de qualquer lugar. Essa migração oferece uma boa oportunidade de examinar a política da sua equipe para os tipos de arquivos e dados que você mantém no controle de versão. Como melhor prática, você deve partir do pressuposto de que tudo que você fizer commit para o GitHub estará comprometido. Portanto, não inclua dados confidenciais, como chaves de API, senhas ou outros arquivos que contêm informações similares.

Observação

O GitHub oferece repositórios públicos e privados, assim como controles de acesso granular para diferentes partes de um repositório. Isso permite que você controle para quem seus projetos ficarão visíveis, bem como as ações que um usuário poderá executar.

Colaboração

O GitHub oferece excelente suporte para colaboração em equipe por meio de recursos como emissões, solicitações de pull e revisões de código. No entanto, o fluxo do GitHub talvez seja diferente das práticas com as quais sua equipe está acostumada atualmente. É uma boa ideia considerar se a equipe vai se adaptar ao GitHub, vai manter o processo determinado ou vai se reunir em algum momento antes da conclusão da migração.

Se o projeto é de código aberto e permite colaboradores externos, não há opção melhor que o GitHub para maximizar os benefícios.

Migrar para o GitHub

Considerações sobre o planejamento

A consideração mais importante antes de executar sua migração para o GitHub é se você precisa manter alguma coisa além do estado atual da sua fonte. Se você estiver satisfeito em iniciar um novo projeto com apenas sua fonte atual no estado em que se encontra, a melhor opção será tratá-lo como um novo projeto e carregar a fonte em seu repositório.

No entanto, se você desejar manter o histórico do controle de versão, será necessário importar usando a ferramenta GitHub Migrator. Para obter mais informações sobre o suporte de importação para diferentes plataformas de controle de versão, confira Importar dados de sistemas de controle de versão de terceiros.

Além dos dados do Git, talvez você deseje manter emissões, solicitações de pull ou outros dados. O suporte a esses itens varia por plataforma e está em disponibilidade geral de projetos da comunidade. Este módulo não cobre a migração de dados que não sejam do Git.

Manipular arquivos binários armazenados no seu projeto no momento

Como uma melhor prática, os repositórios do GitHub devem estar limitados aos arquivos necessários para criar projetos. Evite fazer commit de arquivos binários grandes, como artefatos de compilação. Arquivos binários como planilhas e apresentações são mais adequados para serem acompanhados nos portais que sabem como atendê-los e como controlar a versão deles corretamente. Se você precisar realizar o controle de versão de arquivos binários grandes, considere usar a extensão Git LFS (Armazenamento de Arquivos Grandes) do Git.

Criar arquivos Git importantes como .gitignore

O Git dá suporte a arquivos .gitignore para ajudar a impor políticas de arquivo de controle de versão. Esses arquivos definem os padrões de pesquisa usados para excluir arquivos e pastas do acompanhamento do controle de código-fonte. O exemplo simples a seguir exclui recursivamente quaisquer pastas chamadas Bin ou bine seu conteúdo, do acompanhamento de controle de fonte:

[Bb]in/

Você pode saber mais sobre Ignorar arquivos. Você também pode conferir a coleção de arquivos .gitignore iniciais oferecidos para várias plataformas no repositório gitignore.

Há vários outros arquivos comumente usados em projetos do GitHub para explicar políticas diferentes para consumidores e colaboradores do repositório. Mesmo que seu projeto seja privado e esteja restrito a um público-alvo limitado, ele ainda pode ser útil para articular essas políticas explicitamente. Embora nenhum desses arquivos seja necessário, listamos alguns dos que são comuns aqui.

Arquivo	Finalidade
README.md	A página de aterrissagem do diretório. Esta página é renderizada quando o diretório dela é exibido no GitHub.
LICENSE.md	A licença sob a qual o código é fornecido.
CONTRIBUTING.md	Explica como os usuários devem contribuir com o projeto, como expectativas de solicitação de pull.
SECURITY.md	Explica a política de segurança do projeto. Fornece diretrizes para usuários que desejam enviar código ou comentários confidenciais relacionados à segurança que não devem ser divulgados publicamente antes de serem abordados.

Saiba mais sobre como Configurar seu projeto para contribuições íntegras.

Importar seu projeto para o GitHub

Depois de preparar o repositório para migração, navegue até a guia Código do seu repositório do GitHub. Use a opção Importar código para especificar o repositório de origem.

A ferramenta GitHub Migrator cuidará do restante.