Migrar para o Git a partir do controle de versão centralizado

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

A Microsoft ajudou a migrar muitas equipes internas e clientes de sistemas centralizados de controle de versão para o Git. Esta experiência produziu as seguintes orientações com base em práticas que são consistentemente bem-sucedidas.

Etapas para uma migração bem-sucedida

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

• Avalie as ferramentas e processos atuais.
• Selecione uma estratégia de ramificação do Git.
• Decida se e como migrar o histórico.
• 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 ferramentas e processos atuais

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

As equipes devem considerar a adoção das seguintes práticas ao migrar para o novo sistema:

• Integração contínua (CI), onde cada check-in aciona uma compilação e execução de testes. A CI ajuda a identificar defeitos precocemente e fornece uma forte rede de segurança para projetos.

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

• Entrega contínua (CD) 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.

Selecione 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 de tópicos de curta duração permitem que os desenvolvedores trabalhem perto da ramificação principal e se integrem rapidamente, evitando problemas de mesclagem. Duas estratégias de ramificação de tópicos comuns são o GitFlow e uma variação mais simples, o GitHub Flow.

O Git desencoraja ramificações de recursos isolados e de longa duração, que tendem a atrasar fusões 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 na ramificação principal rapidamente, mas ainda manter os recursos em andamento ocultos dos usuários até que sejam concluídos.

As equipes que atualmente utilizam uma estratégia de ramificação de funcionalidades de longa duração podem adotar flags de funcionalidades antes de migrar para o Git. O uso de sinalizadores de recursos simplifica a migração, minimizando o número de ramificações a serem migradas. Quer utilizem ramificações de funcionalidades ou flags de funcionalidades, as equipas devem documentar o mapeamento entre as ramificações legadas e as novas ramificações do Git, para que todos saibam onde devem submeter o seu novo trabalho.

Decida se deseja migrar o histórico

As equipes podem ficar tentadas a migrar seu histórico de código-fonte existente para o Git. Várias ferramentas afirmam migrar um histórico completo de todas as ramificações de uma ferramenta centralizada para o Git. Uma confirmação Git parece corresponder relativamente bem ao conjunto de alterações ou ao modelo de inserção que a ferramenta de controlo de versão anterior utilizava.

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

• Na maioria dos sistemas de controle de versão centralizados, as ramificações existem como pastas no repositório. Por exemplo, a ramificação 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, as ramificações incluem todo o repositório, portanto, uma tradução 1:1 é difícil.

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

• A maioria dos sistemas de controlo de versão armazena detalhes sobre a forma como os ficheiros mudam entre as versões, incluindo tipos de alteração detalhados, como renomear, restaurar e reverter. O Git armazena versões como instantâneos de todo o repositório e metadados sobre a forma como os arquivos foram alterados não estão disponíveis.

Essas diferenças significam que uma migração completa do histórico será, na melhor das hipóteses, com perda de dados e poderá ser enganosa. Dada a perda, o esforço envolvido e a relativa raridade de usar o histórico, recomenda-se que a maioria das equipes evite importar o histórico. Em vez disso, as equipas devem fazer uma migração de ponta, trazendo apenas uma imagem instantânea da versão de ramo mais recente para o Git. Para a maioria das equipes, o tempo é melhor gasto em áreas da migração que têm um maior retorno sobre o investimento, como a melhoria de processos.

Manter o antigo sistema de controle de versão

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 com o tempo, ainda é importante ser capaz de se referir 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 equipas que fazem apenas uma migração de ponta, é altamente recomendável manter indefinidamente o sistema anterior. Defina o sistema de controle de versão antigo como somente leitura após a migração.

Grandes equipas de desenvolvimento e ambientes regulados podem colocar indicações no Git que apontam de volta para o antigo sistema de controlo de versão. Um exemplo simples é um arquivo de texto adicionado como a primeira confirmação na raiz de um repositório Git, antes da migração de dica, que aponta para a URL do antigo servidor 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 depois que ele foi migrado e 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 versionar arquivos de texto e código-fonte, que são compactos e altamente compressíveis. Os arquivos binários geralmente são grandes e, uma vez adicionados a um repositório, permanecem no histórico do repositório e em todos os clones futuros. Devido à maneira como o Git armazena o histórico, os desenvolvedores devem evitar adicionar arquivos binários aos repositórios, especialmente binários que são muito grandes ou que mudam com frequência. Migrar para o Git é uma oportunidade de remover esses binários da base de código.

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

Ativos como ícones e ilustrações podem precisar estar alinhados com uma versão específica do código-fonte. Ativos pequenos e pouco alterados, como ícones, não incham 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 Gerenciando arquivos grandes. Para Azure Repos, consulte Gerenciar e armazenar arquivos grandes no Git.

Ministrar formação

Um dos maiores desafios na migração para o Git é ajudar os desenvolvedores a entender como o Git armazena as mudanças e como os compromissos formam o histórico de desenvolvimento. Não basta preparar um cheat sheet que mapeie comandos antigos para comandos do 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 gráfico de confirmação.

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

Os cursos de formação práticos gratuitos disponíveis incluem:

• Introdução ao controlo de versão com Git trajeto de aprendizagem.
• O Início rápido do Git no Azure Repos.
• Recursos de aprendizagem sobre Git e GitHub.

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

Testar a migração

Depois que as equipes atualizam seus processos, analisam seu código e treinam seus membros, é hora de migrar o código-fonte. Se você fizer uma migração de dica ou migrar o histórico, é importante fazer uma ou mais migrações de teste para um repositório de teste. Antes de fazer uma migração final, certifique-se de:

• Todos os arquivos de código são migrados.
• Todas as filiais estão disponíveis.
• Não há binários soltos no repositório.
• Os usuários têm as permissões apropriadas para buscar e enviar.
• As compilações são bem-sucedidas 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 os marcos do projeto quando há uma pausa natural. A migração no final de um sprint pode causar problemas enquanto os desenvolvedores estão tentando concluir o trabalho. Tente migrar em um fim de semana, quando ninguém precisa fazer check-in.

Planeje uma transferência firme do antigo sistema de controle de versão 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 antigo sistema de controle de versão como somente leitura para ajudar a evitar confusão. Sem esta salvaguarda, poderá ser necessária uma segunda migração que inclua alterações provisórias.

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 da equipe:

Estratégia de ramificação:

History:

Binários e ferramentas:

Preparação:

Migração de código:

Próximos passos

• Migrar para o Azure DevOps do Team Foundation Server
• Como os comandos TFVC e o fluxo de trabalho são mapeados para o Git