Arquivo da tag: git

Migração do SVN para GIT em Windows no escritório

Olá, pessoal.

Estava devendo uma nova abordagem sobre versionamento aqui, depois de começar o assunto nesse post anterior.

Agora vou mostrar como fiz para implementar a utilização do GIT lá no escritório.

Motivação

Já venho estudando a utilização do GIT faz tempo, desde meados de 2010. Mas ainda não havia me sentido a vontade para começar a implementar nos projetos do escritório que são compartilhados com a equipe.

Mas em casa, nos projetos particulares, e em alguns que não eram utilizados por mais ninguém, comecei a fazer os “git inits”.

Após a ideia da criação do meu domínio na internet (Blog e Empresa), apostei que o desenvolvimento de web apps com a disponibilização de seus código-fonte seria uma ótima forma de treinar a utilização do GIT, e foi mesmo.

No entanto, o que me fez tomar a iniciativa de migrar totalmente nossos repositórios no escritório para GIT foram os constantes problemas no computador que servia para armazenar nossos repositórios SVN.

A cada momento que ele precisava ser levada para manutenção aconteciam esses problemas:

- os colegas paravam de colaborar de forma estruturada: pois o servidor central estava indisponível, não se permitia commits nem updates

- perdia-se o histórico de versionamento do código novo, pois eles começavam a trocar arquivos de um lado para outro (como fazíamos antes de implantar o SVN), sem nenhum método

- eu gastava um tempo muito grande migrando o diretório de repositórios para um novo lugar, e tendo que ensinar o pessoal, mais uma vez, a fazer o svn relocate nas suas cópias locais, além de fazer o mesmo em todos os diretórios de produção manualmente (eu sei, deveria usar alguma ferramenta de deploy, build, integração contínua etc., deixem sugestões nos comentários).

git logo 2

Fonte: http://git-scm.com/

Outro problema constante que faziam o SVN ser uma opção inferior eram:

- tempo de resposta horrível na rede para tudo!!! Isso mesmo, tudo que tínhamos que fazer no SVN depende da rede, e nossa rede do escritório não é uma maravilha. Todo commit, update, log e qualquer outro comando. Era coisa de você literalmente apertar o botão, ir pegar o cafezinho e voltar depois.

E nessa última manutenção, segunda seguida em menos de uma semana, decidi que era gota d’água: mandei um e-mail para todo mundo e “vendi o peixe” do GIT.

Como migrar contando com a resistência natural das pessoas

teimoso

Lembram desse?!?

Lembro como foi para implementar o SVN: além de ter que conhecer o conceito e as ferramentas, o mais importante que é convencer todo mundo a usar com você. Faz bem pouco tempo que o último dos colegas instalou a ferramenta para acessar os repositórios. Muitas aplicações legadas que estão em produção estão sequer versionadas (principalmente aqueles códigos VBA que nunca vi os códigos-fonte).

Mesmo assim, depois de bastante tempo o SVN virou padrão e se tornou um dos nossos pilares para desenvolver nossas aplicações no escritório, aqui em São Paulo. Foi até uma vitória quando consegui implantar ele num projeto que participei na matriz, em Brasília, com um pessoal que foi desde o começo super-resistente a novas ferramentas (torço que ainda esteja funcionando com controle de versões).

Percebi que com o tempo, com você e a equipe tendo mais prática, fica mais simples de mostrar os pontos chave do conceito, e é mais fácil de mostrar que aquilo que propôs é uma boa opção.

E foi dessa forma que consegui converser o pessoal a tentar a migração do SVN. Esse foi um resumo dos argumentos que usei para a utilização do GIT:

- Conceito já maduro, com bastante material para consulta

- Ferramentas com interface gráfica para gerenciar os repositórios (TortoiseGit, o pessoal já usava o TortoiseSvn)

- Os comandos são muito mais rápidos, pois não precisam de acessar a rede nem o repositório central.

- Estou aqui para ajudar!!!

Esse de ajudar o que eu fiz:

- Consegui um monte de material para o pessoal (depois vou colocar os links aqui, mas tinha help do github, bitbucket, etc.). Com o SVN, mas só com o livro oficial

- Baixei os dois programas básicos para eles começarem a utilizar (msysgit e TortoiseGit). No SVN era só o TortoiseSvn

 

logo msysgitlogo tortoise gitlogo msysgitlogo tortoise git

- Acompanhei-os na instalação, mostrei exemplos rápidos de git clone, git init, git push, git pull (lógico que tudo pela interface gráfica do TortoiseGit).

Acho que de tudo a coisa que mais impressionou os colegas foi a rapidez do git. Para mostrar quão rápido ele é (gostei de frisar que muito mais rápido que o Windows), foi numa operação de copiar um diretório versionado na rede para o computador deles. Peguei uma aplicação que montada em cima do Codeigniter, que mesmo não sendo pesada em MBs, tem muitos arquivos, e para transferir isso na nossa rede é uma dureza. Na primeira tentativa mostrei fazendo a “cópia” usando o git clone. E na segunda usei o Windows Explorer, copia cola mesmo. Posso dizer que não deu nem pro cheiro: o git foi muitas vezes mais rápido (não cronometrei mas tenho testemunhas, certo Nelson?).

Futuro

Agora é fazer com que a equipe continue utilizando o GIT nos projetos.

Continuar estudando, aprender melhor todos os conceitos envolvidos (sei que tem um monte) deve fazer essa transição e utilização ser mais tranquila, espero pelo menos do que foi no começo com o SVN.

Acho que a migração de vários projetos de código aberto que utilizamos estarem sendo migrados para GIT, e principalmente para o GitHub deve ser um incentivo ainda maior para continuar mantendo o pessoal focado.

Quem sabe não é até uma forma de ajudar a fazer da equipe uma contribuidora no mundo do software livre, hein?

Até mais.

P.S.0: Estou lendo um livro sobre GIT que estou achando muito bom, dá todos os fundamentos: ProGitPDF, EPUB, MOBI (gratuitos) ou Amazon (pago).

capa do livro Pro Git

P.S.1: Visitem minha conta no GitHub, tem alguns repositórios lá que eu criei e outros forkados

octocat

Fonte: http://octodex.github.com/plumber/

P.S.2: Minha empresa (Pradoj.com), meus apps (Jana, Tati e Cppc).

logo Pradoj.com

 

Este artigo foi publicado originalmente em RogerioPradoJ.com.

Versionamento – SVN e GIT

Meu contato com  controle de versões se deu por causa do framework Symfony, e o seu projeto Jobeet, em meados de 2009.

A ideia de “tirar fotos” do seu projeto em dado momento e ter opção de voltar para ele em algum momento se mostrou muito interessante para mim.

Assim eu não precisaria ter medo de implementar uma nova funcionalidade, ou refatorar  o código de forma alguma: sempre teria como “pegar as fotos” e colocar no lugar do que deu errado.

Por causa do Symfony comecei direto pelo Subversion Version Control (SVN), o que lia na época é que era o mais usado, e que tinha deixado o Control Version System (CVS) para trás. Era comum ver alguns blogs falando já sobre o Git, mas parecia algo muito avançado e mais voltado para o pessoal que desenvolvia em Ruby e Ruby On Rails: como meu foco era PHP, não fui procurar mais nada sobre Git.

Versões/releases no versionamento

O que mais achei interessante da divisão básica entre versões (releases) foi o uso que é feito do Trunk, Branches e Tags.

Para não confundir muito, a partir de agora vou chamar apenas de release essas versões de software.

É comum vermos os softwares com a informação de release dessa forma:

  1. v1, v2, v7
  2. v1.0, v1.3, v5.2
  3. v1.0.3, v1.3.29, v5.6.7

No primeiro item vemos o release principal do programa. Ele geralmente é incrementado quando acontece uma alteração muito grande no software, e não apenas de poucas funções. Um exemplo poderia ser a mudança do Windows XP para o Windows Vista (5 para 6 – fonte).

No segundo item vemos o release de segundo nível. Seu incremento ocorre quando acontece um acréscimo de funcionalidade que não cause uma mudança tão drástica. Exemplo ainda no mundo do Windows, Windows Vista para Windows 7 (6.0 para 6.1 – fonte).

No terceiro item, release de terceiro nível, geralmente usado quando é corrigido um bug num release de segundo nível, ou, nos casos das numerações x.x.0 o release inicial. Esse release é o que costuma ser utilizado pelos clientes.

O Trunk seria para manter a versão de desenvolvimento atual, ou seja, não estaria vinculada diretamente a nenhum dos releases de software acima. Sua tradução literal seria tronco, nesse caso tronco principal. Pensando no controlador de versão como uma árvore essa denominação faz todo o sentido.

Os Branches começam a ter uma maior ligação com releases em si. Sua tradução poderia ser galhos ou ramos, dessa forma cada branch/galho ficaria responsável por um release (geralmente de segundo nível). É comum fazer um branch a partir de um release da seguinte forma:

  • Trunk já está com uma versão suficientemente boa, é feita uma cópia para o Branch v1.0 (release 1.0)
  • Desenvolvedores principais continuam commitando no Trunk, caminhando para o release 2.0
  • Uma funcionalidade nova é criada no Trunk, pensando no release 2.0, mas já querem que seja implementado no versão 1 que está rodando, para isso é criado um novo Branch, agora v1.1 (release 1.1).
  • O trunk continua seu caminho.

As Tags tem mais a ver com o que realmente é distribuído de software para o ambiente de produção. Sua tradução literal seria rótulo ou etiqueta, e é realmente isso que é feito a partir do Branch em determinado momento.

Usando o exemplo acima:

  • O Branch v1.0 será disponibilizado para uso, então ele é etiquetado como Tag v1.0.0
  • A equipe de testes achou uma série de bugs no Branch v1.0, que a equipe de desenvolvimento principal já corrigiu no Trunk.
  • Eles copiam essa correção no Branch v1.0, e etiquetam ele como Tag v1.0.1
  • A nova funcionalidade foi criada e eles querem disponibilizar para uso, é criado o Branch v1.1.
  • Logo após esse Branch é etiquetado como Tag v1.1.0.
  • A equipe de testes agora acha um bug no Branch v1.1, a equipe de desenvolvimento já corrigiu no Trunk.
  • É copiada a correção para o Branch v1.1, e etiquetada nesse momento como Tag v1.1.1.
  • Outro bug é achado no Branch v1.1, é copiada a correção do Trunk para esse Branch e é etiquetada como Tag v1.1.2.

SVN

Como na minha empresa o SVN era um software homologado, foi mais fácil também aplica-lo lá, o que facilitou meu aprendizado.

Em vez de ir direto para a linha de comando, preferi utilizar o TortoiseSVN. Ele tem integração com o Windows Explorer e facilita muito o trabalho de criação de repositórios, checkouts, updates e commits.

Minha fonte de informação inicial, depois do Symfony – Jobeet, foi o livro do SVN em inglês, no endereço http://svnbook.red-bean.com/

Depois de muita procurar em blogs em português, consegui a versão do livro em português pt-br, endereço: https://code.google.com/p/svnbook-pt-br/

Quando fiquei mais natural no uso do SVN, arriscando quase nada um pouco na linha de comando e migrando 99% para o Ubuntu Linux, comecei a procurar outras opções que não fossem o Tortoise.

No Ubuntu a primeira ferramenta que achei que fazia um pouco o que o Tortoise oferecia no Windows foi o RapidSVN. Só que ele não tinha integração com o Nautilus Mais tarde meu irmão @royopa me mostrou o RabbitVCS, que já se integrava bem naturalmente com meu gerenciador de arquivos. Posso afirmar: é o TortoiseSVN para Linux.

Como todas essas ferramentas, funcionalidades e entendimento que passei a ter do SVN pensei: acho que agora é hora de aprender algo novo.

Git

Comecei a ver que muitos projetos PHP e outros de meu interesse já estavam passando para o GitHub (CakePHP, Symfony2, jQuery…).

Era tempo de começar a me arriscar nesse mundo também.

Seguindo uma dica de a lista de PHP do Twitter do @rogeriomaxmax consegui o livro http://net.tutsplus.com/freebies/books/getting-good-with-git-free-ebook/

Estou bem no início, mas enquanto vou caminhando, irei postando o que vou conseguindo.

Até mais,

—–

Atualizado em 19/10/2010 as 00h43: Terminei o livro de Git.

Minha página no GitHub é: http://rogeriopradoj.github.com.

Vamos caminhando…

Este artigo foi publicado originalmente em RogerioPradoJ.com.