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

Esta é a segunda parte do artigo que mostra as razões para você mudar do Subversion para Git. A primeira parte você lê aqui.

?

Tornando-se um artista de código

Você chega em casa na sexta-feira depois de uma longa semana de trabalho. Enquanto você se senta na sua poltrona tomando cerveja e comendo Cheetos, você tem uma ideia de tirar o fôlego. Então, você pega o seu laptop e começa a trabalhar na sua ideia incrível durante todo o fim de semana, mexendo em metade dos arquivos no seu projeto e tornando a coisa 87 vezes mais incrível. Agora você começa a trabalhar e se  conecta à VPN e finalmente consegue fazer o commit. A pergunta agora é: o que você faz? Um grande commit barulhento? Quais são suas outras opções?

No Git, isso não é um problema. O Git tem um recurso único chamado de “staging area”, o que significa que você pode criar cada commit no ultimo minuto, transformando seu fim de semana de trabalho insano em um série de conjuntos de mudanças logicamente separadas e bem pensadas. Se você editou um monte de arquivos e quer criar um monte de commits que contenham apenas alguns arquivos cada, você simplesmente tem que organizar apenas os que você quiser antes de fazer o commit e repetir isso algumas vezes.

$ git add file1.c file2.c file3.c
$ git commit -m 'files 1-3 for feature A'
$ git add file4.c file5.c file6.c
$ git commit -m 'files 4-6 for feature B'

Isso permite que outras pessoas que estejam tentando entender o que você tenha feito revisem os peers do seu trabalho. Se você mudou três coisas logicamente diferentes no seu projeto, você pode fazer o commit delas como três diferentes e revisáveis conjuntos de mudanças o mais tarde possível.

Não somente isso, o que já é bastante poderoso, o Git também facilita a organização de partes de arquivos. Esse é um recurso que preveniu um suicídio entre colegas no meu passado profissional. Se alguém tivesse mudado 100 linhas de um arquivo, das quais 96 eram espaços em branco e comentários de modificações de formatação, e as 4 que faltavam eram mudanças significativas na lógica do negócio, a revisão dos peers, se tivesse sido feito o comitt como uma única mudança, seria um pesadelo. Ser capaz de organizar as mudanças no espaço em branco em um commit com uma mensagem apropriada, e então organizar e fazer o commit das mudanças da lógica do negocio separadamente é um salva-vidas (literalmente, pode salvar sua vida de seus peers). Para fazer isso, você pode usar o recurso patch staging do Git, que pergunta se você quer organizar as mudanças em um grande arquivo por vez (git add -p).

Essas ferramentas permitem que você crie seus commits para serem facilmente revisáveis, cherry-pickable, separarem logicamente as mudanças do seu projeto. As vantagens de pensar no histórico do seu projeto dessa maneira e de ter as ferramentas para facilmente manter essa disciplina sem ter que planejar cuidadosamente cada commit mais que alguns segundos antes de ter que criá-los, te dá uma liberdade e uma flexibilidade que são bastante poderosas.

No Subversion, a única maneira real de conseguir o mesmo resultado é com um complicado sistema de jogar as diferenças para arquivos temporários, revertendo e aplicando parcialmente esses arquivos temporários novamente. Levante a mão se você já usou seu tempo de fato para fazer isso e se você consideraria o processo “fácil” de alguma maneira. Os usuários do Git muitas vezes fazem esse tipo de operação diariamente, e você não precisa de nada de fora do Git para realizá-la.

Não é justo para equipes de codificadores

Ouço das pessoas o tempo todo que não valeria a pena a troca, porque elas não trabalham em grandes equipes ou não colaboram com outras pessoas. Ou talvez você não seja verdadeiramente um programador, mas um designer ou um escritor.

Bem, na disputa indivíduo versus time, eu discutiria que quase tudo que eu amo sobre o Git, muito do que escrevi aqui, eu amo porque me ajuda, não porque ajuda meus colegas de equipe. Danem-se eles.

Branching local e troca de contexto sem atrito é inteiramente útil para qualquer pessoa, e provavelmente o recurso mais revolucionário e único do Git. Na verdade, muitas vezes eu uso o Git como você deve usar o RCS – apenas acione-o em algum diretório local e verifique as coisas de vez em quando, sem ter nenhum repositório remoto. Criar commits como conjuntos de mudanças logicamente separados também é útil para você se lembrar de por que fez algo um mês atrás, então essas ferramentas são úuteis para indivíduos e, finalmente, velocidade e backup são sempre coisas boas, para equipes ou para indivíduos.

Se você não for um desenvolvedor de software, eu já listei um exemplo de como usar o Git para colocar em um livro. O Pro Git está sendo publicado pela Apress, e a maior parte da escrita e da revisão do livro foi feita em Markdown usando Git como colaboração. Todas as erratas e as traduções estão sendo feitas em branches do Git. Você não conhece a verdadeira felicidade da escrita até que você entra em revisões técnicas ou em modificações das cópias dos editores com algo tão simples como `git merge`.

Finalizando…

Finalizando, isso é apenas um pouquinho do quão incrível é o Git. Existe uma tonelada de recursos poderosos no Git que ajudam com debugging, complex diffing e merging, e mais. Existe também uma ótima comunidade de desenvolvimento para você dar uma olhada e se tornar parte, e vários recursos grátis online para te ajudar a aprender e a usar o Git. As poucas coisas que mencionei aqui são simplesmente os recursos que mais mudaram a maneira como penso sobre trabalho e controle de versões. Eles são a principal razão pela qual eu nunca voltaria para um sistema como o Subversion. Seria como dizer “você tem que usar um Toyota em vez de um Mercedes”, seria como dizer “você tem que usar uma máquina de escrever em vez de um computador” – ele mudou completamente a maneira como abordo e penso sobre como criar as coisas.

Quero compartilhar com você o conceito de que você pode pensar sobre controle de versão não como uma inconveniência necessária que você tem que aguentar para conseguir colaborar, mas sim como um framework poderoso para gerenciar seu trabalho separadamente em contextos, sendo capaz de trocar e de fundir entre aqueles contextos rápido e facilmente, sendo capaz de tomar decisões tardias e de criar seu trabalho sem ter que pré-planejar tudo o tempo todo. O Git deixa todas essas coisas mais fáceis e as prioriza, e deve mudar a maneira como você pensa sobre como abordar um problema em qualquer um de seus projetos e nos próprios controles de versão.

?

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