Recentemente passei a utlizar git em todos os meus projetos (depois de sofrer muito com a lentidão do sourceforge e outros repositórios svn).

Me atrapalhei um pouco no começo por não entender os conceitos por trás de repositórios distribuídos, mas no fim das contas o que realmente era importante é que o meu fluxo de trabalho tinha mudado e eu não estava entendendo isso direito até eu pedir para o Fábio Kung sentar do meu lado e me explicar o workflow com o git. Como muitos não tem a chance de fazer isso, aqui fica o que eu aprendi (e estou usando com frequência agora).

1. Clonar um repositório: Antes de mais nada você precisa ter um repositório para trabalhar. Com git, você faz isso clonando um repositório já existente (semelhante ao checkout do svn)

   git clone URL_REPOSITORIO PASTA_LOCAL_PARA_ARQUIVOS
   

   Com isso foi criado o seu branch principal, chamado master.

2. Criar um branch de trabalho: Uma das maiores vantagens do git é a facilidade com que você pode trocar de branch a fazer merge. Se você não usar branch, perde muito do que o git te proporciona.

   git checkout -b work
   

   checkout é o comando para você trocar de branch. Se você acrescentar um “-b”, ele também cria o branch pra você. Chamei meu branch de work, mas ele poderia ter qualquer outro nome.

3. Programe e faça commits pequenos: Como os commits feitos em git são sempre locais, você pode fazer commits bem pequenos, que são bem mais fáceis de fazer merge caso ocorra um conflito.

   git commit -a -m "mensagem de commit"
   

   Lembrem-se sempre de que mensagens de commit são importantes. Escreva mensagens que esclarecem o que foi feito.
   Além disso, a flag “-a” que eu coloquei ali indica para o git commitar todas as modificações que foram feitas. Se você quiser algo mais granular, pode usar:

   git add NOME_DO_ARQUIVO
   

   ou

   git add -i
   

   No qual você pode escolher os arquivos a commitar. Bem interessante.
   Não esqueça de fazer o commit sem o “-a” depois se for fazer assim.

4. Download de alterações que outras pessoas com acesso ao repositório tenham feito: Você não trabalha sozinho em geral e sempre que você for enviar algo para o repositório alguém já terá enviado antes. O que vamos fazer agora é trazer essas atualizações.

   git checkout master
   git pull origin master
   

   Na primeira vez que você tentar dar pull você tem que informar de onde (origin) e para onde (master). Depois você pode apenas usar git pull, porque o git é espertinho e lembra o que você quer.

5. Rebase do work: Como todas as suas modificações estão no work, você conseguiu trazer as modificações para a máquina, mas agora seu branch work está desatualizado com relação ao master. Essa é a maior maravilha do git. Você vai temporariamente remover as modificações do work, aplicar os commits que estão no master e reaplicar seus commits.

   git checkout work
   git rebase master
   

6. Resolvendo os conflitos: Pode acontecer do git não conseguir resolver algum dos conflitos de modificação. Quando isso ocorre ele para o rebase para que você resolva os conflitos, commit a commit e não tudo de uma vez como o svn.

   git mergetool
   git rebase --continue
   

   O git mergetool abre uma ferramenta visual para merging (facilita muito a vida). O git rebase –continue fala para continuar o rebase.

7. Enviando modificações para o servidor remoto: Quando você termina o rebase, seu repositório está novamente compatível com o do servidor remoto. Basta agora aplicar essas modificações no master e enviar para o remoto.

   git checkout master
   git merge work
   git push origin master
   

   O comando git merge work aplica seus commits no master. O git push envia para o servidor remoto. Novamente, na primeira vez que você tentar isso, o git ainda não sabe o que nem para onde você quer mandar. Por isso você precisa informar.

É um pouco mais trabalhoso que o svn, mas os ganhos são significativos. Vale a pena usar git direito. Eu não volto mais pro svn.

Posts Relacionados:

Acompanhe-nos por RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.

Uma das coisas que mais me atrapalhava com o svn era quando eu queria gerar um snapshot do que tinha no repositório, mas sem os .svn .

Um one-liner bash que faz isso:

	find . -iname .svn | xargs rm -fr

Explicação:

1. find . -iname .svn: Encontra todos os arquivos ou diretórios que se chamem .svn
2. xargs rm -fr: O xargs é um programa que executa o que vier depois dele pra cada linha que ele receber como entrada. Por isso apaga todos os .svn.

Posts Relacionados:

Acompanhe-nos por RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.

Na segunda palestra que assisti (na verdade terceira, mas a primeira não conta porque, infelizmente, dormi :P), Sylvestre Mergulhão deu continuidade à palestra do Fabio Akita e falou sobre escalabilidade utilizando Rails no site RedeParede, um site de classificados com versões para toda a América Latina.

Sylvestre começou falando da performance do site e o sistema de indexação do Google (o Googlebot). Falou que o Googlebot afetava perceptivelmente a performance do site quando estava indexando e era responsável por aproximadamente metade das requisições. Levantou também algumas teorias sobre o Googlebot (parte que achei mais interessante na palestra):

1. Sitemap em XML => mais visitas
2. Rank também é determinado por capacidade do site de receber visitas
3. Queda de serviço => menos indexação por um bom tempo
4. Mais atualizações => mais indexação

Depois disso, Mergulhão falou um pouco sobre a estrutura física dos servidores do site. São seis máquinas atrás de um balanceador de carga, cada uma com cinco instâncias rodando atrás do NGINX. Falou também um pouco do memcached, utilizado para fazer cache de qualquer string, que está sendo utilizado em massa pelo site. Segundo ele, é uma biblioteca fácil de usar, apesar de pouca documentação. Deu também exemplos de configuração e de uso. Falou mais um pouco sobre problemas com caching (página muda de acordo com usuário) e sobre outros tipos de caching: de página (falou que era melhor usar o cache de HTTP com ETags), de ações (muito interessante: permite guardar o resultado de uma ação no cache; dobrou a capacidade de processamento do servidor deles) e de fragmentos (para guardar pedaços de páginas).

Por fim, falou um pouco sobre o ganho de performance e de tempo de desenvolvimento (por não ter que usar mais SQL) com o uso do Sphinx.

O começo da palestra foi interessante, mas minha impressão final é de que o palestrante não ficou muito feliz com o resultado da migração do site, antes em PHP, para Rails. Outro comentário que posso fazer é que já trabalhei num projeto em Rails com Sphinx e a equipe não gostou muito; acabamos mudando para o Solr.

Posts Relacionados:

Acompanhe-nos por RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.

Ontem, Fabio Akita deu uma palestra no FISL 10 sobre Ruby on Rails. Foi uma palestra lotada e divertida.

A palestra começou com uma breve introdução ao arcabouço, um outline da palestra. O Fabio falou de como surgiu o arcabouço, qual era seu objetivo inicial, falou das atuais versões de Ruby, de Rails e do JRuby e da importância da comunidade para o projeto.

Em seguida, na parte mais divertida da palestra, o Akita mostrou alguns dados sobre a performance da máquina virtual de Ruby. Mostrou, por exemplo, o ganho de velocidade da versão 1.8 para a versão 1.9 da máquina virtual “padrão” de Ruby por meio de um jogo muito interessante chamado “Rubystein” que eu, pelo menos, não conhecia nessa versão… hehehe). O jogo, aliás, utiliza uma biblioteca para acessar o hardware diretamente para fazer o desenho 2D: Gosu.

Depois da demostração de ganho de velocidade realmente impressionante da nova máquina virtual, falou um pouco da importância da comunidade para se aprender e divulgar Ruby on Rails. Citou, inclusive, alguns sites muito bons para ficar por dentro das últimas novidades sobre o projeto:

• Peepcode
• railsenvy.com (podcasts)
• railscasts.com (vídeo podcasts de how-to’s)
• Outros…

Em seguida, Fabio falou de alguns recursos que já vem embutidos no Rails mas que nem todo mundo lembra, motivo pelo qual, segundo ele, algumas pessoas xingam Rails sem motivo. Dentre essas funcionalidades, vale destacar o suporte a autenticação HTTP básica, Atom, internacionalização (i18n para os íntimos), XML, JSON, e-mail e caching.

Para terminar, o Akita fez uma demonstração de algumas funcionalidades incrementando o já famoso blog de 15 minutos. Criou uma área de administração com login, colocou caching, um editor de texto mais incrementado e suporte a upload de arquivos, para citar as mais legais.

Enfim, aprendi algumas coisas novas com essa palestra; gostei! E acho que também agradou a quem não conhecia quase nada de Rails. Parabéns, Akita. Mas faltou alguma coisa de metodologias ágeis na palestra (pelo título).

O código que ele mostrou na palestra está no GitHub e os slides, no SlideShare.

Assim que der tempo falo sobre as outras três palestras que assisti ontem, apesar da visita do nosso presidente ter atrapalhado um pouco o andamento do evento…

Posts Relacionados:

Acompanhe-nos por RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.