Seções iMasters
Desenvolvimento

Por que você deveria mudar do Subversion para Git – Parte 01

Você deve ter ouvido um falatório sobre sistemas de controles de versões distribuídos recentemente. Você não deve considerá-las a coisa mais nova do momento, o novo sabor de tang satisfazendo a sede dos populares. Você, no entanto, tem usado o Subversion por algum tempo. Ele tem te tratado bem, você o conhece bem e se sente confortável com ele – digo, é apenas um controle de versão, certo?

Você pode querer dar uma segunda olhada nisso. Não somente em de sistemas de controles de versões distribuídos, mas também no real papel do controle de versões no seu kit de ferramentas criativas. Neste artigo, de duas partes, irei introduzi-lo ao Git, meu DVCS favorito, e esperançosamente te mostrar por que ele não é somente um melhor sistema de controle de versões que o Subversion, mas também uma maneira revolucionária de pensar sobre como fazer o seu trabalho.

Agora, este artigo não é exatamente um “como fazer” do Git – eu não irei falar sobre comandos específicos ou deixar você pronto para trabalhar. Esta é uma lista de argumentos sobre por que você deveria estar seriamente considerando o Git se você está atualmente usando o SVN. Para aprender Git, existe um livre online grátis chamado Pro Git que eu escrevi e que irá te mostrar o Git passo-a-passo, se este artigo te interessar. Para cada ponto que eu fizer aqui, irei linkar a seção apropriada do livro, se você quiser saber mais sobre um recurso específico do Git.

Então, primeiro, iremos dar uma olhada nas vantagens inerentes dos sistemas distribuídos em relação aos sistemas centralizados. Essas são coisas que sistemas como o Subversion simplesmente não conseguem fazer. Então iremos cobrir as ferramentas de troca de contexto e criação de arquivo que são tecnicamente possíveis de fazer com o Subversion, mas o Git as torna fácil o suficiente, de modo que você pode fato usá-las. Essas ferramentas devem mudar completamente a maneira como você trabalha e a forma como você pensa sobre trabalho.

As vantagens de ser distribuído

Git é um sistema de controle de versão distribuído. Então, o que “distribuído” significa? Bom, significa que em vez de executar `svn checkout (url)` para pegar a última versão do seu repositório, com o Git você roda `git clone (url)`, o que dá a você uma cópia completa de toda o histórico daquele projeto. Isso significa que imediatamente depois do clone, não existe basicamente nenhuma informação sobre aquele projeto que o servidor do qual você clonou tenha que você não tenha. Curiosamente, o Subversion é tão ineficiente nisso que, em geral, é quase tão rápido clonar um repositório inteiro no Git quanto fazer o checkout de uma única versão do mesmo repositório no Subversion.

Agora, isso te dá algumas vantagens imediatas. Uma é que quase toda a operação agora é feita off data no seu disco local, o que significa que é incrivelmente rápido e pode ser feito offline. Isso significa que você pode fazer commits, diffs, logs, branches, merges, file annotation e mais – inteiramente offline, off VPN, e geralmente instantaneamente. A maior parte dos comandos que você executa em Git levam mais tempo para digitar do que para serem executados. Agora pare por um instante e tente se lembrar de quantas vezes você foi buscar uma xícara de café enquanto o Subversion estava rodando algum comando. Ou tome nota de uma lista de ocasiões em que você quis fazer o commit, mas não tinha conexão com a internet ou não conseguia se conectar à sua VPN corporativa.

A outra vantagem implícita desse modelo é que seu fluxo de trabalho não tem um único ponto de falha. Como cada pessoa que trabalha no seu projeto tem o que é essencialmente um backup completo dos dados do projeto, perder seus servidores de colaboração é uma pequena inconveniência, no máximo. Imagine, por um momento, seu servidor SVN tendo uma séria corrupção de drive – quando foi seu último backup e quantas horas vão demorar para que sua equipe possa voltar a trabalhar? No Git, qualquer membro da equipe pode enviar arquivos para qualquer servidor onde exista acesso via SSH para qualquer membro, e toda a equipe pode facilmente estar pronta para trabalhar em uma questão de minutos.

A vantagem final que cobrirei de sistemas distribuídos são os incríveis fluxos de trabalho que agora estão disponíveis para você. O Git não depende de um servidor central, mas tem a habilidade de sincronizar com outros repositórios Git – para pegar e levar as mudanças entre eles. Isso significa que você pode adicionar múltiplos repositórios remotos ao seu projeto, alguns somente de leitura e outros com possibilidade de acesso de escrita também, o que significa que você pode ter quase qualquer tipo de fluxo de trabalho em que você pode pensar.

Você pode continuar usando um fluxo de trabalho centralizado, com um servidor central que todo mundo usa. No entanto, você também pode fazer coisas mais interessantes. Por exemplo, você pode ter um repositório remoto para cada usuário ou sub-time no seu grupo a que eles têm acesso de escrita, em seguida um mantenedor ou time de QA ou integrador pode juntar seu trabalho e colocá-lo em um repositório de “ouro” de onde é feito o deploy.

Você pode construir qualquer tipo de modelo de fluxo de trabalho baseado em peers em que você puder pensar, além de ser capaz de usá-lo como um hub centralizado como no SVN. Seu fluxo de trabalho pode crescer e se adaptar de acordo com seu modelo de negócios.

Você também pode usá-lo de outras maneiras – um exemplo interessante disso é o deploy na Heroku, empresa de hospedagem do Ruby. Para efetuar o deploy nos sistemas deles, você simplesmente envia seu repositório remoto ‘heroku’. Você pode desenvolver e colaborar em outros repositórios remotos, mas quando você de fato quiser fazer o deploy do seu código em servidores que estiverem rodando, você envia para o repositóro Heroku no Git. Imagine tentar fazer isso com o Subversion.

Branches leves: alternância de contexto sem atrito

Antes de eu começar a explicar isso, que é meu recurso favorito no Git, eu preciso que você me faça um favor. Esqueça tudo que você sabe sobre branches. Seu conhecimento do que ‘branch’ significa no Subversion é venenoso, especialmente se você o internalizou antes do 1.5, como eu, antes de o Subversion ter construído algumas capacidades básicas de rastreamento de merges. Esqueça quão doloroso era executar o merge, esqueça quanto tempo demorava para alternar entre branches, esqueça quão impossível era fazer o merge de um branch mais de uma vez – o Git te dá um mundo todo novo no que se trata de branching e merging.

No Git, branches não são uma palavra feia – eles são mais vezes usados e fundidas, em muitos casos os desenvolvedores criam um para cada recurso em que eles estão trabalhando e os unem várias vezes em um dia, e geralmente isso é tranquilo. Isso foi o que me prendeu ao Git em primeiro lugar, e mudou completamente a maneira como eu abordo meu desenvolvimento.

Quando você cria um branch no Git, ele faz de modo local e isso acontece de maneira bem rápida. Aqui está um exemplo da criação de um branch e então a troca para um novo branch para começar a fazer o desenvolvimento.

$ time git branch myidea
real 0m0.009s
user 0m0.002s
sys 0m0.005s

$ time git checkout myidea
Switched to branch "myidea"
real 0m0.298s
user 0m0.004s
sys 0m0.017s

Levou cerca de um terço de segundo para ambos os comandos serem executados juntos. Pense por um segundo sobre o equivalente no Subversion – executar um `copy` e então um `switch`.

$ time svn copy -m 'my idea'  \

real 0m5.172s
user 0m0.033s
sys 0m0.016s

$ time svn switch
real 0m8.404s
user 0m0.153s
sys 0m0.835s

Agora a diferença entre 1/3 de segundo e 13 segundos (sem mencionar o tempo que leva para lembrar cada URL longa) pode não parecer grande no início, mas existe uma significativa diferença psicológica ali. Adicione isso à velocidade da sua rede, ao carregamento do servidor, e ao status de conectividade, fatores no Subversion que no Git sempre levam 1/3 de segundo e fazem uma grande diferença. Além disso, o branching é considerado uma operação rápida no Subversion – você verá diferenças ainda mais consideráveis em outras operações comuns como log e diff.

No entanto, esse não é o verdadeiro poder dos branches no Git. O poder real é como você os usa, a velocidade crua e a facilidade dos comandos simplesmente o torna mais provável de ser utilizado. No Git, um caso de uso comum é criar um novo branch local para tudo em que você trabalha. Cada recurso, cada ideia, cada correção de bug – você pode facilmente criar um novo branch facilmente, executar alguns commits nesse branch e então ou executar um merge na sua linha principal de trabalho ou jogá-lo fora. Você não tem que bagunçar a linha principal para salvar suas ideias experimentais, não tem que estar online para fazer isso e, mais importante, pode alternar o contexto quase que instantaneamente.

Agora, uma vez que você tenha trabalho em uns dois branches, e o merginf? Se você for do mundo do Subversion, você pode tremer quando ouvir a palavra ‘merge’. Como o Git grava todo o seu histórico de commit como um gráfico direcionado de commits, geralmente é fácil para ele entender automaticamente qual a melhor base de merge para fazer um merge com vários elementos. A maior parte dos usuários do Subversion está acostumada a ter que descobrir isso manualmente, o que um processo propenso a erros e que leva tempo – o Git o torna trivial. Além disso, você pode executar o merge a partir do mesmo branch várias vezes e não precisa resolver os mesmos conflitos de novo e de novo. Geralmente eu faço dezenas de merges por dia em certos projetos do Git e raramente tenho conflitos triviais de merge no Git – certamente nada que não seja previsível. Levante a mão se você já fez dezenas de merges de branch em um projeto do Subversion pelo menos uma vez por semana e não acabou cada dia bebendo demais.

Como uma anedota de caso de estudo, pegue meu Pro Git book. Eu coloquei a fonte do livro no GitHub, o site de hospedagem para o qual trabalho. Em alguns dias, eu comecei a receber dezenas de pessoas fazendo forks do meu projeto e contribuindo com edições de cópias, correções e até traduções. No Git, cada um desses forks é tratado como um branch que eu poderia pegar e fazer o merge individualmente. Eu gastei alguns minutos uma ou duas vezes por semana para pegar todo o trabalho que tinha sido feito, inspecionar cada branch e fazer o merge das aprovadas na linha principal.


No momento em que estava escrevendo este artigo, eu tinha feito 34 merges em cerca de 2 semanas – eu me sentei de manhã e fiz o merge em todas os branches que pareciam boas. Como exemplo, durante a ultima sessão do merge, eu inspecionei e fiz o merge em 5 branches separados em 13 minutos. Mais uma vez, eu irei deixar isso como um exercício para o leitor contemplar como teria sido no Subversion.

Na segunda parte do artigo, você verá como se tornar um artista de código e mais exemplos das vantagens do Git.

?

Texto original disponível em http://thinkvitamin.com/code/why-you-should-switch-from-subversion-to-git/

Mensagem do anunciante:

Torne-se um Parceiro de Software Intel®. Filie-se ao Intel® Developer Zone. Intel®Developer Zone

Comente também

6 Comentários

José

Git > SVN. Fato.

Eduardo Matos

Show de bola!

Renato Silva Medina

Bacana essa explicação. É o que todos sabem, mas muita gente finge que não vê.

verdade

Nao vejo necessidade nenhuma de ter todo o historico offline.

Paulo

Muito interessante esta abordagem, me ajudou muito, obrigado e parabéns!

Robson Cruz

Bacana, esta abordagem mudou meu ponto de vista, parabéns!

Qual a sua opinião?