Close

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

Em Por que o Git?, a gente discutiu as várias maneiras pelas quais o Git pode ajudar sua equipe a se tornar mais ágil. Assim que decidir fazer a mudança, seu próximo passo é descobrir como migrar seu fluxo de trabalho de desenvolvimento existente para o Git.

Este artigo mostra algumas das maiores alterações com as quais você vai se deparar ao fazer a transição de sua equipe do SVN para o Git. O mais importante a se ter em mente durante o processo de migração é que o Git não é SVN. Para entender todo o potencial do Git, tente ao máximo se abrir para novas formas de pensar sobre o controle de versão.


Para administradores


A adoção do Git pode levar de alguns dias a vários meses, dependendo do tamanho da sua equipe. Esta seção aborda algumas das principais preocupações dos gerentes de engenharia quando se trata de treinar funcionários no Git e migrar repositórios do SVN para o Git.

Comandos básicos do Git


O Git já teve a reputação de ter uma grande curva de aprendizado. No entanto, os mantenedores do Git têm lançado novas melhorias de forma constante, como padrões sensíveis e mensagens de ajuda contextuais que tornaram o processo de integração muito mais agradável.

A Atlassian oferece uma série abrangente de tutoriais individualizados do Git, bem como webinars e sessões de treinamento ao vivo. Juntos, devem fornecer todas as opções de treinamento que sua equipe precisa para começar a usar o Git. Para começar, aqui está uma lista de alguns comandos básicos do Git para você dar os primeiros passos:

bancos de dados
Material relacionado

Como mover um Repositório do Git completo

Logotipo do Bitbucket
VER SOLUÇÃO

Aprenda a usar o Git com o Bitbucket Cloud

Tarefa do Git

Notas

Comandos do Git

Dizer ao Git quem é você

Notas

Configurar o nome do autor e o endereço de e-mail a serem usados com seus commits. Observe que o Git retira alguns caracteres (por exemplo, pontos finais) de user.name.

Comandos do Git

git config --global user.name "Sam Smith"git config --global user.email sam@example.com

Criar um novo repositório local

Notes

 

Comandos do Git

git init

Consultar um repositório

Notas

Criar uma cópia de trabalho de um repositório local:

Comandos do Git

git clone /path/to/repository

 

Notas

Para um servidor remoto, use:

Comandos do Git

git clone username@host:/path/to/repository

Adicionar arquivos

Notas

Adicionar um ou mais arquivos ao staging (índice):

Comandos do Git

git add *

Commit

Notas

Fazer commit das alterações no head (mas não ainda no repositório remoto):

Comandos do Git

git commit -m "Commit message"

 

Notas

Fazer o commit de todos os arquivos adicionados com o git add e de todos os arquivos que você alterou desde então:

Comandos do Git

git commit -a

Empurrar

Notas

Enviar as alterações à ramificação principal do seu repositório remoto:

Comandos do Git

git push origin main

Status

Notas

Listar os arquivos que você alterou e aqueles que você ainda precisa adicionar ou fazer o commit:

Comandos do Git

git status

Conexão com um repositório remoto

Notas

Se você não conectou seu repositório local a um servidor remoto, adicione o servidor para poder fazer envios a ele:

Comandos do Git

git remote add origin

 

Notas

Listar todos os repositórios remotos configurados no momento:

Comandos do Git

git remote -v

Ramificações

Notas

Criar uma nova ramificação e mudar para ela:

Comandos do Git

git checkout -b

 

Notas

Mudar de um ramificação para outra:

Comandos do Git

git checkout

 

Notas

Listar todas as ramificações em seu repositório e informar em qual ramificação você está no momento:

Comandos do Git

Git Branch

 

Notas

Excluir a ramificação de característica:

Comandos do Git

git branch -d

 

Notas

Enviar a ramificação ao seu repositório remoto, para que outros possam fazer uso dela:

Comandos do Git

git push origin

 

Notas

Enviar todas as ramificações ao repositório remoto:

Comandos do Git

git push --all origin

 

Notas

Exclua uma ramificação do seu repositório remoto:

Comandos do Git

git push origin :

Atualizar do repositório remoto

Notas

Buscar e fazer o merge das alterações no servidor remoto para o seu diretório de trabalho:

Comandos do Git

git pull

 

Notas

Para mesclar uma ramificação diferente em sua ramificação ativa:

Comandos do Git

Git merge

 

Notas

Exibir todos os conflitos de merge:Exibir os conflitos do arquivo base:Visualizar alterações antes do merge:

Comandos do Git

git diff
git diff --base
git diff

 

Notas

Após resolver os conflitos de modo manual, marca o arquivo alterado:

Comandos do Git

git add

Marcações

Notas

Você pode usar a marcação para marcar um conjunto de alterações significativo, como uma versão:

Comandos do Git

git tag 1.0.0

 

Notas

CommitID são os caracteres principais do ID do conjunto de alterações, até 10, mas devem ser exclusivos. Obtenha o ID usando:

Comandos do Git

git log

 

Notas

Enviar todas as marcações ao repositório remoto:

Comandos do Git

git push --tags origin

Desfazer alterações locais

Notas

Se você cometer algum erro, é possível substituir as alterações em sua árvore de trabalho pelo último conteúdo em head. Alterações já adicionadas ao índice, bem como novos arquivos, são mantidas.

Comandos do Git

git checkout --

 

Notas

Em vez disso, para descartar todas as alterações e commits locais, busque o histórico mais recente do servidor e aponte sua ramificação principal local para ele, da seguinte forma:

Comandos do Git

git fetch origingit reset --hard origin/main

Pesquisar

Notas

Pesquisar no diretório de trabalho por foo():

Comandos do Git

git grep "foo()"

Ferramentas de migração do Git


Há várias ferramentas disponíveis para ajudar você a migrar seus projetos existentes do SVN para o Git, mas antes de decidir quais ferramentas usar, é preciso descobrir como quer migrar seu código. As opções são:

  • Migre toda a sua base de código para o Git e pare de usar o SVN.
  • Não migre nenhum projeto existente para o Git, mas use o Git para todos os novos projetos.
  • Migre alguns de seus projetos para o Git enquanto continua utilizando o SVN para outros projetos.
  • Use SVN e Git de modo simultâneo nos mesmos projetos.

Uma transição completa para o Git limita a complexidade do fluxo de trabalho de desenvolvimento, portanto, essa é a opção preferencial. No entanto, isso nem sempre é possível em empresas maiores com dezenas de equipes de desenvolvimento e centenas de potenciais projetos. Nessas situações, uma abordagem híbrida é uma opção mais segura.

A(s) ferramenta(s) de migração a serem utilizadas depende muito de qual das estratégias acima você escolher. Algumas das ferramentas de migração de SVN para Git mais comuns são apresentadas abaixo.

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".

Para desenvolvedores


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.

Conclusão


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.


Compartilhar este artigo

Leitura recomendada

Marque esses recursos para aprender sobre os tipos de equipes de DevOps ou para obter atualizações contínuas sobre DevOps na Atlassian.

Pessoas colaborando usando uma parede cheia de ferramentas

Blog do Bitbucket

Ilustração do DevOps

Caminho de aprendizagem de DevOps

Demonstrações de funções no Demo Den com parceiros da Atlassian

Como o Bitbucket Cloud funciona com o Atlassian Open DevOps

Inscreva-se para receber a newsletter de DevOps

Thank you for signing up