SVN para Git – preparando-se para a migração

Scripts de migração da Atlassian

Se você estiver interessado em fazer uma transição abrupta para o Git, os scripts de migração da Atlassian são uma boa opção para você. Eles fornecem todas as ferramentas necessárias para converter seus repositórios SVN existentes em repositórios do Git com segurança. O histórico do Git nativo resultante garante que não vai ser preciso lidar com nenhum item de interoperabilidade do SVN para Git após o processo de conversão.

A gente fornece um passo a passo técnico completo de utilização desses scripts para converter toda a sua base de código em uma coleção de repositórios do Git. O passo a passo explica tudo, desde a extração de informações do autor do SVN até a reorganização das estruturas de repositório SVN não padrão.

Plugin SVN Mirror para Stash (agora Bitbucket)

SVN Mirror para StashO SVN Mirror para Stash é um plugin do Bitbucket que permite manter com facilidade uma base de código híbrida que funciona com o SVN e o Git. Ao contrário dos scripts de migração da Atlassian, o SVN Mirror para Stash permite utilizar o Git e o SVN de forma simultânea no mesmo projeto pelo tempo que quiser.

Essa solução de compromisso é uma ótima opção para grandes empresas. Ela possibilita a adoção incremental do Git, permitindo que diferentes equipes migrem fluxos de trabalho conforme a necessidade.

O que é Git-SVN?

A ferramenta git-svn é uma interface entre um repositório do Git local e um repositório SVN remoto. O git-svn permite que os desenvolvedores criem códigos e commits locais com o Git e, em seguida, os enviem a um repositório SVN central com comportamento no estilo svn commit. Essa ação deve ser temporária, porém, é útil ao discutir a mudança do SVN para o Git.

O git svn é uma boa opção se você não tiver certeza sobre a mudança para o Git e quiser que alguns de seus desenvolvedores explorem os comandos do Git sem se comprometer com uma migração total. Também é perfeito para a fase de treinamento – em vez de uma transição abrupta, sua equipe pode treinar com facilidade os comandos locais do Git antes de se preocupar com fluxos de trabalho de colaboração.

Observe que o git svn deve ser apenas uma fase temporária do seu processo de migração. Como ele ainda depende do SVN para o “back-end”, não pode aproveitar as características mais poderosas do Git, como ramificações ou fluxos de trabalho de colaboração avançada.

Estratégias de implementação

Migrar sua base de código é apenas um aspecto da adoção do Git. Também é preciso considerar como apresentar o Git aos responsáveis por essa base de código. Consultores externos, especialistas internos em Git e equipes piloto são as três principais estratégias para mover sua equipe de desenvolvimento para o Git.

Consultores externos do Git

Em resumo, os consultores do Git podem lidar com o processo de migração para você por uma taxa nominal. Isso tem a vantagem de criar um fluxo de trabalho do Git sob medida para sua equipe sem investir tempo para descobertas por conta própria. Também disponibilizam a você recursos de treinamento de parceiros enquanto sua equipe está aprendendo a usar o Git. Os parceiros da Atlassian são especialistas quando se trata da migração de SVN para Git e são uma boa opção ao contratar um consultor de Git.

Por outro lado, projetar e implementar um fluxo de trabalho do Git por conta própria é uma ótima maneira da sua equipe entender o funcionamento interno do seu novo processo de desenvolvimento. Isso evita o risco da sua equipe ficar sem saber o que fazer na ausência do consultor.

Especialistas internos em Git

São os desenvolvedores dentro da sua empresa que estão animados para começar a usar o Git. Aproveitar esses talentos é uma boa opção para empresas com uma forte cultura de desenvolvedores e programadores entusiasmados que se sentem à vontade para serem os primeiros a adotar o Git. A ideia é possibilitar a um de seus engenheiros que ele se torne um especialista em Git para que possa projetar um fluxo de trabalho do Git personalizado para sua empresa e atuar como consultor interno quando chegar a hora de fazer a transição do restante da equipe para o Git.

Comparado a um consultor externo, há a vantagem de se ter um especialista em Git internamente. No entanto, é necessário investir um tempo maior para treinar esse especialista e há o risco de se escolher o fluxo de trabalho do Git errado ou realizar a sua implementação de modo incorreto.

Equipes piloto

A terceira opção de transição para o Git é fazer testes com ele em uma equipe piloto. Ela funciona melhor se você tiver uma equipe pequena que trabalha, de certa maneira, em um projeto isolado. Pode funcionar ainda melhor ao unir, na equipe piloto, consultores externos com especialistas internos em Git para uma combinação imbatível.

Essa opção tem a vantagem de exigir a adesão de toda a equipe e também limita o risco de escolher o fluxo de trabalho errado, já que recebe informações de toda a equipe ao elaborar o novo processo de desenvolvimento. Em outras palavras, garante que todas as peças que faltam sejam reunidas mais rápido do que quando um consultor ou especialista projeta o novo fluxo de trabalho por conta própria.

Por outro lado, usar uma equipe piloto requer mais treinamento inicial e tempo de configuração: em vez de um desenvolvedor identificar um novo fluxo de trabalho, há uma equipe inteira que pode, durante algum tempo, ser menos produtiva até se sentirem confortáveis com seu novo fluxo de trabalho. No entanto, essa dificuldade temporária vale o ganho a longo prazo.

Segurança e permissões

O controle de acesso é um aspecto do Git no qual vai ser necessário repensar o modo como você gerencia sua base de código.

Via de regra, no SVN toda a sua base de código é armazenada em um único repositório central e, em seguida, o acesso às pastas é limitado a diferentes equipes ou indivíduos. No Git, isso não é possível: os desenvolvedores devem recuperar o repositório inteiro para trabalhar com ele. De modo geral, não se pode recuperar um subconjunto do repositório como é feito no SVN. Permissões só podem ser concedidas a repositórios inteiros do Git.

Você precisa dividir seu grande repositório SVN em vários repositório do Git menores. Na verdade, a gente experimentou isso em primeira mão aqui na Atlassian quando a equipe de desenvolvimento do Jira migrou para o Git. Todos os plugins do Jira costumavam ser armazenados em um único repositório SVN, mas após a migração, cada plugin está em seu próprio repositório.

Lembre-se de que o Git foi projetado para integrar com segurança as contribuições de código de milhares de desenvolvedores Linux independentes, portanto, ele fornece meios para a configuração de qualquer tipo de controle de acesso que sua equipe precise. Isso pode, no entanto, exigir uma nova visão do seu ciclo de desenvolvimento.

Caso haja interesse em manter dependências entre sua nova coleção de repositórios do Git, ter uma camada de gerenciamento de dependências no Git pode ser útil. Uma camada de gerenciamento de dependências vai ajudar nos tempos de build pois, à medida que um projeto cresce, é necessário “armazenamento em cache” para acelerar o tempo de build. Uma lista com as ferramentas recomendadas de camada de gerenciamento de dependências para cada pilha de tecnologia pode ser encontrada neste artigo útil: Dependências do" Git e do projeto".

Um repositório para cada desenvolvedor

Como desenvolvedor, a maior alteração à qual você vai precisar se ajustar é a natureza distribuída do Git. Em vez de um único repositório central, cada desenvolvedor tem sua própria cópia de todo o repositório. Isso altera de forma significativa a maneira como você colabora com seus programadores.

Em vez de verificar um repositório SVN com o svn checkout e obter uma cópia de trabalho, todo o repositório do Git é clonado para sua máquina local com o git clone.

A colaboração ocorre ao mover ramificações entre repositórios com os comandos git push, git fetch ou git pull. O compartilhamento, em geral, é feito no nível da ramificação no Git, mas pode ser feito no nível do commit, semelhante ao SVN. Mas no Git, um commit representa o estado total de todo o projeto em vez de modificações de arquivo. Como você pode usar ramificações no Git e no SVN, a diferença importante aqui é que você pode fazer o commit local com o Git, sem compartilhar seu trabalho. Isso permite a você experimentar com mais liberdade, trabalhar off-line de forma mais eficaz e acelerar quase todos os comandos relacionados ao controle de versão.

No entanto, é importante entender que um repositório remoto não é um link direto para o repositório de outra pessoa. É um simples marcador que poupa você de digitar novamente o URL completo toda vez que interagir com um repositório remoto. Até que você envie um pull ou uma ramificação de modo explícito a um repositório remoto, você está trabalhando em um ambiente isolado.

O outro grande ajuste para os usuários do SVN é a noção de repositórios “locais” e “remotos”. Os repositórios locais estão em sua máquina local e todos os outros repositórios são chamados de repositórios remotos. O principal objetivo de um repositório remoto é disponibilizar seu código ao restante da equipe e, portanto, não é realizado nenhum desenvolvimento ativo nele. Os repositórios locais estão situados em sua máquina local e é onde é feito todo o desenvolvimento de software.

Não tenha medo de ramificações ou de mesclagens

No SVN, o commit do código é feito ao editar os arquivos em sua cópia de trabalho e, em seguida, executando o svn commit para enviar o código ao repositório central. Outras pessoas podem então enviar um pull dessas alterações em suas próprias cópias de trabalho com o svn update. De modo geral, as ramificações do SVN são reservadas para aspectos grandes e de longa duração de um projeto, pois o merge é um procedimento perigoso que tem o potencial de interromper o projeto.

O fluxo de trabalho de desenvolvimento básico do Git é muito diferente. Em vez de estar vinculado a uma única linha de desenvolvimento (por exemplo, trunk/), tudo gira em torno de ramificações e merge.

Quando você quer começar a trabalhar em algo no Git, você cria e consulta uma nova ramificação com git checkout -b. Isso oferece uma linha de desenvolvimento dedicada onde você pode criar códigos sem se preocupar em afetar outra pessoa da sua equipe. Se algum erro for causado e a correção não for possível, basta excluir a ramificação com git branch -d. Se você criar algo útil, crie uma pull request pedindo o merge na ramificação principal.

Fluxos de trabalho potenciais do Git

Ao escolher um fluxo de trabalho do Git, é importante considerar as necessidades da sua equipe. Um fluxo de trabalho simples pode maximizar a velocidade e a flexibilidade do desenvolvimento, enquanto um fluxo de trabalho mais complexo pode garantir maior consistência e controle do trabalho em andamento. Você pode adaptar e combinar as abordagens gerais listadas abaixo para atender às suas necessidades e às diferentes funções da sua equipe. Um desenvolvedor principal pode usar ramificações de característica enquanto um prestador de serviço trabalha em uma bifurcação, por exemplo.

• Um fluxo de trabalho centralizado fornece a correspondência mais próxima aos processos SVN comuns, por isso é uma boa opção para começar.
• Com base nessa ideia, usar um fluxo de trabalho de ramificação de características permite que os desenvolvedores mantenham seu trabalho em andamento isolado e ramificações compartilhadas importantes protegidas. As ramificações de características também formam a base para o gerenciamento de alterações por meio de solicitações pull.
• Um fluxo de trabalho do Gitflow é uma extensão mais formal e estruturada da ramificação de características, o que o torna uma ótima opção para equipes maiores com ciclos de lançamento bem definidos.
• Por fim, considere um fluxo de trabalho de bifurcação se precisar de isolamento e controle máximos sobre as alterações ou se houver muitos desenvolvedores contribuindo em um repositório.

Mas, se você quer tirar o máximo proveito do Git como uma equipe profissional, você deve considerar o fluxo de trabalho da ramificação de características. Esse é um fluxo de trabalho com distribuição genuína, alta segurança, escalabilidade incrível e ágil por natureza.

A transição da sua equipe para o Git pode ser uma tarefa intimidante, mas não precisa ser. Este artigo apresentou algumas das opções comuns para a migrar sua base de código existente, implementar o Git em suas equipes de desenvolvimento e lidar com segurança e permissões. Os maiores desafios para os quais seus desenvolvedores devem estar preparados durante o processo de migração também foram apresentamos.

Esperamos que agora você tenha uma base sólida para introduzir o desenvolvimento distribuído em sua empresa, independentemente do porte ou das práticas de desenvolvimento atuais.