Alberto Leal

Não sei nem por onde começar.. =P

Sem dúvidas o melhor evento o qual já participei! Superou completamente as minhas espectativas. O evento foi dividido em dois dias, sendo que os keynotes foram apresentados durante toda a manhã e o período da tarde foi dividido em três tracks. Haviam momentos em que era praticamente impossível escolher entre uma track e outra.

Organização?! Nota 10! Evento muito bem trabalhado, muito bem conduzido. Parabéns a Caelum e toda a equipe que estava de alguma forma envolvida com o andamento do evento.

Coffe break?! Não tem como deixar de comentar: O coffee break foi animal!! Toda vez que você saia da sala a mesa estava lá, sempre cheia de comida e bebida. Teve coffee break o tempo inteiro!!

Networking?! Foi muito bacana poder conhecer pessoas que só conhecia pela internet, além de re-encontrar velhos amigos.

Happy Hour?! O local escolhido para o happy hour foi um barzinho localizado próximo ao evento. O problema aqui foi que tinha tanta gente que, foi impossível colocar todo mundo “junto”. Uma galera ficou no último andar do bar, enquanto que outra parte ficou no primeiro andar. Mas isso nem atrapalhou muito, deu para rir bastante, trocar altas idéias…

Lightning Talk?! Até eu fiz uma apresentação no QConSP. Foi no final do primeiro dia. Contei um pouco sobre a forma como minha equipe utiliza o Git: “Utilizando Git em Projetos com Repositório Centralizado”. Mostrei uma pequena aplicação que utilizamos para ajudar a fazer a entrega em um repositório centralizado (qualquer dia eu blogo sobre isso em detalhes)

Obrigado pela foto, @Loiane!

Projeto no Github: http://github.com/albertoleal/Git-To-Central-Repository

Quem saca bastante de SVN, CVS, fique a vontade para fazer um fork. Aliás, seria bem interessante poder ter esta aplicação voltada para outros SCM. =)

#CaravanaJavaCE?! Demais!! Muito legal pode re-encontrar a galera e conhecer outros membros da comunidade Cearense!

Pontos Negativos?! Foram distribuídos fones de ouvido para que as pessoas que não tem o domínio da língua inglesa pudessem acompanhar a tradução  simultânea feita pelo Paulo e Guilherme. Só que a galera colocava este fone no último volume. Com isso, acabava atrapalhando outras pessoas que não precisavam do fone. E não dava para fugir, pois sempre tinha um fone alto em algum lugar =( Isto foi uma coisa que atrapalhou, mas que ao meu ver não estava no controle da organização do evento. Outro ponto que acho que poderia mudar é: Divulgar o nível da palestra no site. Por exemplo: Deixei de assistir uma palestra para assistir outra, achando que ia aprofundar no assunto, mas não aconteceu. Isto me deixou um pouco “frustado”. Outra sugestão é: Achei que faltou um “lounge”. Seria legal ter um no próximo, para que as pessoas possam usufruir do espaço: descansando, batendo papo..

Então, é isso! Espero poder participar do próximo. Com certeza estarei presente =D

(E ainda tem gente falando que o evento foi caro.. tsc tsc)

Olá Pessoal,

Neste último final de semana eu gravei um screencast de como criar um branch vazio no Git.

Espero que vocês gostem:

Creating an empty branch on Git from Alberto Leal on Vimeo.

Abraços.

Hoje vou dar uma dica rápida de como recuperar um arquivo em commits anteriores.
Cenário: Você está trabalhando em um arquivo e adicionou ele em alguns commit. Mas, depois de alguns minutos, você percebe que as mudanças que você está fazendo estão incorretas, e necessita recuperar a versão que você havia adicionado no commit anterior. Como fazer isso? Vamos ver:

1
2
3
4
5
6
7
8
9

$ touch abc.txt
$ vim abc.txt
$ git add abc.txt
$ git commmit -m 'Abc file'
$ vim abc.txt
$ git add abc.txt
$ git commmit -m 'Some changes'
$ cat abc.txt
$ git checkout HEAD^1 -- abc.txt

O comando é ‘git checkout HEAD^1 — abc.txt’,  onde o número 1 representa a quantidade de commits abaixo, a partir do HEAD, e abc.txt representa o nome do arquivo que você deseja recuperar.

Simples e bastante útil!

Cenário: Você está em uma reunião participando de um code review, quando algum desenvolvedor vira e fala: “Quem comentou a linha 12? Eu fiz esse código e aquele fragmento era importante!”. Pergunta: O culpado aparece rápido? Pode ser que sim. Mas, caso não apareça  ninguém para assumir a culpa, utilize o comando ‘git blame’ para descobrir quem fez cada modificação.

Exemplo:

$ git blame workspace/ProjectXPTO/WebContent/file.jsp -L 10,18
73e51f4f (Desenvolvedor A 2009-03-10 09:07:53 -0400 10)
73e51f4f (Desenvolvedor A 2009-03-10 09:07:53 -0400 11)  <script>
73e51f4f (Desenvolvedor A 2009-03-10 09:07:53 -0400 12)         // var windowName;
7ue8d049 (Desenvolvedor B 2009-06-18 16:42:48 -0400 13)
7ue8d049 (Desenvolvedor B 2009-06-18 16:42:48 -0400 14) function cleanUpVariable(variable){
7ue8d049 (Desenvolvedor B 2009-06-18 16:42:48 -0400 15)  var = j;
7ue8d049 (Desenvolvedor B 2009-06-18 16:42:48 -0400 16)  j = variable.replace(/[^0-9A-Za-z]+/g, "");
7ue8d049 (Desenvolvedor B 2009-06-18 16:42:48 -0400 17)  return j;
7ue8d049 (Desenvolvedor B 2009-06-18 16:42:48 -0400 18) }

Se você não passar o parâmetro -L serão exibidas todas as linhas do seu arquivo.  No caso acima deu para perceber que o responsável por comentar a variável “windowName” foi o “Desenvolvedor A”.

Agora você já sabe como descobrir quem faz cada besteira nos seus arquivos.

Acredito que o título desse post diz muito por si só. Mas, vou tentar expandí-lo um pouco mais. Só para constar, fui impulsionado a escrever esse post devido a algumas mensagens que acompanhei pelo twitter.

–

Existem diversos controladores de versão no mercado, tais como: Harvest, CVS, SVN, Clear Quest e por aí vai. Porém, o Git possui uma idéia, filosofia diferente destes que acabei de citar. Git é um SCM distribuído. Não vou entrar em detalhes sobre as diferenças agora, vamos deixar para uma outra ocasião.

A mensagem que quero passar é a seguinte:
Git é difícil?  Não.
Uso SVN/CVS na minha empresa há muitos anos, posso mudar tudo de uma vez para o GIT - já que Git não é difícil? Não aconselho.

Usar um controlador de versão não envolve apenas adicionar arquivos e comitá-los. Existem diversas tarefas que, às vezes, temos que fazer, como por exemplo: Quebrando um commit e cancelando algumas alterações. Pode ser que você já saiba fazê-lo no outro SCM que você vem utilizando, mas ainda não sabe fazê-lo no Git.

Se você, simplesmente, mudar de SCM de uma hora para a outra fatalmente terá problemas e terá que recorrer ao grande amigo Google. Alguns problemas triviais não lhe tomará muito tempo, por outro lado, outros não serão tão triviais quanto possam parecer e tomarão mais tempo do que você gostaria.

Minha sugestão é a seguinte, comece utilizando Git em um projeto antes de migrar todos os outros. Desse jeito você perceberá como o Git trabalha e como tirar o maior proveito dele. Além de se deparar com os mais diversos tipos de problemas.

Até a próxima!

Você sabe quando usar o cherry-pick ou am/apply?

Algumas vezes eu ficava confuso em qual comando usar. Se você se confunde, aí vai a dica:

Uma utilização para esses comandos é quando você desejar fazer o rebase/merge entre branches que estão em árvores diferentes, ou seja, vamos imaginar que você tem um branch, chamado A, que foi criado à partir do branch Release0615, e tem outro branch, chamado B, que foi criado à partir do branch Release0630.

O seu branch A atrasou e suas alterações não entrarão mais na release 0615 (release do dia 15/06/2009), então você deve fazer o seu rebase/merge com o release 0630. Mas eles estão em árvores diferentes, com isso você pode ter uma série, digo novamente, uma série de problemas. Uma solução é levar apenas as suas modificações feitas no branch A para o branch B, removendo com isso os conflitos de arquivos que você sequer mexeu!

Agora, qual comando usar ‘git cherry-pick’ ou ‘git format-patch’ seguido de ‘git am -3′ ou ‘git apply’?

Se o branch estiver em ambiente local utilize ‘git cherry-pick’. Ele tentará fazer um auto-merge para você e se não existir conflito tudo estará pronto. Agora, por outro lado, se os commits não estiver no ambiente local, ou se alguém lhe enviou os arquivos .patch por email, você deve usar o comando ‘git am -3′ ou ‘git apply’. Prefira utilizar ‘git am -3′, pois com ele o git já vai saber que são commits de outra árvore e fará de tudo para não ter problema no merge.

Tenho percebido que algumas pessoas estão caindo no meu blog procurando por “como desfazer commit no git”.

Aí vai uma dica rápida para aqueles que estão à procura de uma solução.

Sempre que for desejável desfazer um commit no git, basta você revertê-lo. Para isso, utilize o seguinte comando:

1

git revert nome_do_commit

Se você executar o comando acima por acidente, você consegue revertê-lo também. Fazendo o revert do revert você estará voltando para o estado inicial do seu commit.

Espero que ajude!