Compartilhar via

Migrar para o Git do controle de versão centralizado

Migrar uma equipe para o Git do controle de versão centralizado requer mais do que apenas aprender novos comandos. Para dar suporte ao desenvolvimento distribuído, o Git armazena o histórico de arquivos e informações de branch de forma diferente de um sistema de controle de versão centralizado. Planejar e implementar uma migração bem-sucedida para o Git de um sistema de controle de versão centralizado requer a compreensão dessas diferenças fundamentais.

A Microsoft ajudou a migrar muitas equipes internas e clientes de sistemas de controle de versão centralizados para o Git. Essa experiência produziu as diretrizes a seguir com base em práticas que têm êxito consistentemente.

Etapas para migração bem-sucedida

Para uma migração bem-sucedida, as equipes devem:

  • Avalie as ferramentas e os processos atuais.
  • Selecione uma estratégia de ramificação do Git.
  • Decida se vai migrar o histórico e como.
  • Mantenha o sistema de controle de versão anterior.
  • Remova arquivos binários, executáveis e ferramentas do controle do código-fonte.
  • Treinar equipes em conceitos e práticas do Git.
  • Teste a migração para o Git.

Avaliar as ferramentas e os processos atuais

Alterar sistemas de controle de versão naturalmente interrompe o fluxo de trabalho de desenvolvimento com novas ferramentas e práticas. Essa interrupção pode ser uma oportunidade para melhorar outros aspectos do processo de DevOps.

As equipes devem considerar a adoção das seguintes práticas à medida que migram para o novo sistema:

  • CI (integração contínua), em que cada check-in dispara um processo de build e teste. A CI ajuda a identificar defeitos antecipadamente e fornece uma rede de segurança forte para projetos.

  • Revisões de código obrigatórias antes de integrar o código. No modelo de ramificação do Git, a revisão do código de solicitação de pull faz parte do processo de desenvolvimento. As revisões de código complementam o fluxo de trabalho de CI.

  • CD (entrega contínua) para automatizar os processos de implantação. A alteração das ferramentas de controle de versão requer alterações no processo de implantação, portanto, uma migração é um bom momento para adotar um pipeline de lançamento moderno.

Selecionar uma estratégia de ramificação do Git

Antes de migrar o código, a equipe deve selecionar uma estratégia de ramificação.

No Git, ramificações temáticas de curta duração permitem que os desenvolvedores trabalhem próximo à ramificação principal e se integrem rapidamente, evitando problemas de fusões. Duas estratégias comuns de branch de tópico são o GitFlow e uma variação mais simples, o GitHub Flow.

O Git desencoraja branches de recursos isolados de longa duração, que tendem a atrasar mesclagens até que a integração se torne difícil. Usando técnicas modernas de CD, como sinalizadores de recursos, as equipes podem integrar o código ao branch principal rapidamente, mas ainda manter os recursos em andamento ocultos dos usuários até que eles sejam concluídos.

As equipes que atualmente usam uma estratégia de branch de recursos de longa duração podem adotar sinalizadores de recursos antes de migrar para o Git. O uso de sinalizadores de funcionalidades simplifica a migração, minimizando o número de branches a serem migrados. Se eles usam branches de recursos ou sinalizadores de recursos, as equipes devem documentar o mapeamento entre branches herdados e novos branches do Git, para que todos entendam onde confirmar seu novo trabalho.

Decidir se deseja migrar o histórico

Equipes podem ser tentadas a migrar seu histórico de código-fonte existente para o Git. Várias ferramentas afirmam migrar um histórico completo de todos os branches de uma ferramenta centralizada para o Git. Uma confirmação no Git se ajusta relativamente bem ao conjunto de mudanças ou ao modelo de check-in utilizado pela ferramenta anterior de controle de versão.

No entanto, esse mapeamento tem algumas limitações sérias.

  • Na maioria dos sistemas de controle de versão centralizados, os branches existem como pastas no repositório. Por exemplo, o branch principal pode ser uma pasta chamada /trunk e outras ramificações são pastas como /branch/one e /branch/two. Em um repositório Git, os branches incluem todo o repositório, portanto, uma tradução 1:1 é difícil.

  • Em alguns sistemas de controle de versão, uma marca ou rótulo é uma coleção que pode conter vários arquivos na árvore, até mesmo arquivos em versões diferentes. No Git, um tag é um instantâneo de todo o repositório em um ponto específico no tempo. Uma marca não pode representar um subconjunto do repositório ou combinar arquivos em versões diferentes.

  • A maioria dos sistemas de controle de versão armazena detalhes sobre como os arquivos mudam entre versões, incluindo tipos de alteração refinados, como renomeação, undelete e reversão. O Git armazena versões como instantâneos de todo o repositório, e os metadados sobre como os arquivos mudaram não estão disponíveis.

Essas diferenças significam que uma migração completa do histórico será, na melhor das hipóteses, propensa a perdas e possivelmente enganosa. Dada a perda, o esforço envolvido e a raridade relativa do uso do histórico, é recomendável que a maioria das equipes evite importar o histórico. Em vez disso, as equipes devem fazer uma migração de ponta, trazendo apenas um instantâneo da versão mais recente do branch para o Git. Para a maioria das equipes, o tempo é melhor gasto em áreas da migração que têm um retorno maior sobre o investimento, como melhorar os processos.

Manter o sistema de controle de versão antigo

Durante e após uma migração, os desenvolvedores ainda podem precisar de acesso ao histórico de controle de versão anterior. Embora o histórico de controle de versão anterior se torne menos relevante ao longo do tempo, ainda é importante poder fazer referência a ele. Ambientes altamente regulamentados podem ter requisitos legais e de auditoria específicos para o histórico de controle de versão.

Especialmente para equipes que fazem apenas uma migração de gorjeta, é altamente recomendável manter o sistema anterior indefinidamente. Defina o sistema de controle de versão antigo como somente leitura após a migração.

Grandes equipes de desenvolvimento e ambientes regulamentados podem colocar referências no Git que apontam para o sistema de controle de versão antigo. Um exemplo simples é um arquivo de texto adicionado como o primeiro commit na raiz de um repositório Git, antes da migração de ponta, que aponta para a URL do servidor antigo de controle de versão. Se muitas ramificações migrarem, um arquivo de texto em cada ramificação deverá explicar como as ramificações migraram do sistema antigo. "Breadcrumbs também são úteis para desenvolvedores que começam a trabalhar em um projeto após sua migração e que não estão familiarizados com o antigo sistema de controle de versão."

Remover arquivos binários e ferramentas

O modelo de armazenamento do Git é otimizado para o controle de versão de arquivos de texto e código-fonte, que são compactos e altamente compactados. Os arquivos binários geralmente são grandes e, depois de adicionados a um repositório, eles permanecem no histórico do repositório e em cada clone futuro. Devido à maneira como o Git armazena o histórico, os desenvolvedores devem evitar adicionar arquivos binários a repositórios, especialmente binários muito grandes ou que mudam com frequência. Migrar para o Git é uma oportunidade para remover esses binários da base de código.

Também é recomendável excluir bibliotecas, ferramentas e saída de build de repositórios. Em vez disso, use sistemas de gerenciamento de pacotes como o NuGet para gerenciar dependências.

Ativos como ícones e arte podem precisar se alinhar a uma versão específica do código-fonte. Ativos pequenos e raramente alterados, como ícones, não sobrecarregam o histórico e você pode incluí-los diretamente em um repositório. Para armazenar ativos grandes ou que mudam com frequência, use a extensão Git Large File Storage (LFS). Para obter mais informações sobre como gerenciar arquivos grandes no GitHub, consulte Gerenciamento de arquivos grandes. Para o Azure Repos, consulte Gerenciar e armazenar arquivos grandes no Git.

Fornecer treinamento

Um dos maiores desafios na migração para o Git é ajudar os desenvolvedores a entender como o Git armazena alterações e como confirma o histórico de desenvolvimento de formulários. Não basta preparar um guia rápido que mapeie comandos antigos para comandos Git. Os desenvolvedores precisam parar de pensar no histórico de controle de versão em termos de um modelo centralizado e linear e entender o modelo de histórico do Git e o grafo de confirmação.

As pessoas aprendem de maneiras diferentes, portanto, você deve fornecer vários tipos de materiais de treinamento. O treinamento ao vivo baseado em laboratório com um instrutor especialista funciona bem para algumas pessoas. O livro do Git Pro é um excelente ponto de partida que está disponível gratuitamente online.

Os cursos de treinamento práticos disponíveis incluem:

As organizações devem trabalhar para identificar especialistas do Git em equipes, capacitá-los para ajudar outras pessoas e incentivar outros membros da equipe a fazer perguntas.

Testar a migração

Depois que as equipes atualizarem seus processos, analisarem o código e treinarem seus membros, é hora de migrar o código-fonte. Se você fizer uma migração de dicas ou migrar o histórico, é importante fazer uma ou mais migrações de teste para um repositório de testes. Antes de fazer uma migração final, verifique se:

  • Todos os arquivos de código são migrados.
  • Todas as ramificações estão disponíveis.
  • Não há binários perdidos no repositório.
  • Os usuários têm as permissões apropriadas para buscar e puxar.
  • Os builds são bem-sucedidos e todos os testes são aprovados.

Migrar o código

Faça a migração final fora do horário de trabalho, idealmente entre etapas quando houver tempo de inatividade natural. A migração no final de um sprint pode causar problemas enquanto os desenvolvedores estão tentando concluir o trabalho. Tente migrar durante um fim de semana, quando ninguém precisar fazer check-in.

Planeje uma substituição firme do sistema de controle de versão antigo para o Git. Tentar operar vários sistemas em paralelo significa que os desenvolvedores podem não saber onde ou como fazer check-in. Defina o sistema de controle de versão antigo como somente leitura para ajudar a evitar confusão. Sem essa proteção, uma segunda migração que inclui alterações provisórias pode ser necessária.

O processo de migração real varia dependendo do sistema do qual você está migrando. Para obter informações sobre como migrar do Controle de Versão do Team Foundation, consulte Migrar do TFVC para o Git.

Lista de verificação de migração

Fluxos de trabalho de equipe:

  • Determine como as compilações serão executadas.
  • Decida quando os testes serão executados.
  • Desenvolva um processo de gerenciamento de versão.
  • Mover revisões de código para solicitações de pull.

Estratégia de ramificação:

  • Escolha uma estratégia de ramificação do Git.
  • Documente a estratégia de ramificação, por que ela foi selecionada e como os branches herdados são mapeados.

History:

  • Decida por quanto tempo manter o controle de versão herdado em execução.
  • Identifique branches que precisam ser migrados.
  • Se necessário, crie trilhas para ajudar os engenheiros a navegar de volta para o sistema herdado.

Binários e ferramentas:

  • Identifique quais binários e arquivos não diferenciáveis remover do repositório.
  • Decida uma abordagem, como o Git-LFS, para arquivos grandes.
  • Decida uma abordagem para fornecer ferramentas e bibliotecas, como o NuGet.

Formação:

  • Identificar materiais de treinamento.
  • Planeje eventos de treinamento, materiais escritos e vídeos.
  • Identifique os membros da equipe para servirem como especialistas locais do Git.

Migração de código:

  • Faça várias execuções de teste para garantir que a migração vá bem.
  • Identifique e comunique um momento de transição.
  • Crie o novo repositório Git.
  • Defina o sistema antigo como somente leitura.
  • Migre a ramificação principal primeiro e, em seguida, quaisquer outras ramificações necessárias.

Próximas etapas

  • Last updated on