Depois que eu passei a trabalhar com git, o eclipse começou a me torrar muito a paciência. Toda vez que eu mudava de branch ele perguntava se eu queria atualizar os arquivos abertos. E depois eu tinha que atualizar o projeto para tudo voltar a funcionar.

Depois de quase me conformar, vi um tweet do Miško Hevery (http://twitter.com/mhevery/statuses/3439314089) com exatamente a solução para o problema.

Você só precisa ir em Preferences -> General -> Workspace e marcar refresh automatically. Essa foi umas das descobertas que mais melhorou meu humor nos últimos tempos.

Posts Relacionados:

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

O post de hoje é do nosso amigo Lucas Cavalcanti, desenvolvedor da Caelum.

Usando git, sempre é bom trabalhar em branches, nunca commitar diretamente na branch master.

Acontece que às vezes você simplesmente esquece de criar uma branch antes de começar a trabalhar
e commita várias coisas no master. O problema disso é que se você der um git pull origin master
e acontecer um conflito de merge, você vai ter que resolver todos os conflitos de uma vez só,
e ganhar um commit “Merge branch blablablah” que some com algumas informações de commit…

O que fazer então?

Um jeito legal de prevenir isso é digitando os comandos:


(master) $ git branch temp
# cria uma branch pra guardar o estado atual


(master) $ git reset --hard HEAD@{1}
# volta o estado do branch master para a última
# ação perigosa que você fez, geralmente
# o último push que vc fez no servidor


(master) $ git pull origin master
# agora sim fazendo um pull seguro


(master) $ git checkout temp
(temp) $ git rebase master
# e corrige os eventuais conflitos do jeito certo


(temp) $ git checkout master
(master) $ git merge temp
(master) $ git push origin master
(master) $ git branch -d temp


Assim você corrige a cagada de trabalhar no master sem querer e continua a trabalhar com o git
do jeito certo.

Posts Relacionados:

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

Umas das coisas legais que bash tem é uma variável que define como deve ser o prompt da linha de comando. Essa variavel de ambiente se chama PS1. Um dos usos mais incríveis que já vi dela foi o de mostrar em qual branch do git você está (e não mostrar nada quando você não está em um repositório).

Isso é a diferença entre

e isso

Não sei quanto a vocês, mas eu realmente fico mais feliz com a segunda forma.

A minha variável PS1 é configurada da seguinte forma (mac - ~/.bash_profile - linux - ~/.bashrc):

export PS1="\[\033[38m\]\u\[\033[32m\] \w \[\033[31m\]\`git \\
branch 2>/dev/null | grep \"^\*\" | \\
sed -r \"s/\*\ (.*)/ \(\1\)/\"\`\[\033[37m\]$\[\033[00m\] "

Impossível de ler, correto? Vou quebrar em mais linhas para facilitar a vida.

PS1="\[\033[38m\]\u";
PS1="$PS1\[\033[32m\] \w";
PS1="$PS1\[\033[31m\]";
PS1="$PS1\`git branch 2>/dev/null | grep \"^\*\" | \\
                           sed -r \"s/\*\ (.*)/ \(\1\)/\"\`";
export PS1="$PS1\[\033[37m\]$\[\033[00m\]";

Não testei, mas deve ter o mesmo efeito. Explicando um pouco da mágica:

1. Essa sequência bizarra de caracteres (\[\033[38m\]) é a forma de definir que o que virá depois será impresso em branco, num terminal que permite coloração (o que realmente define a cor é o 38m. O resto é apenas a forma de indicar a mudança de cor). “\u”, na PS1, significa o usuário atual.
2. A próxima sequência de caracteres bizarros troca a cor para verde. “\w”, na PS1, é o seu path atual.
3. Troca a cor para vermelho.
4. Extrai o nome do branch (sendo executado em uma subshell. Para isso que servem os \`).
   1. git branch 2>/dev/null: Imprime todos os branches do repositório onde você se encontra. Caso ocorra algum erro, a mensagem de erro será enviada para /dev/null, vulgo limbo (por isso nada será impresso nos outros diretórios).
   2. grep “^\*”: Me dá todas as linhas começadas por * .
   3. sed -r \”s/\*\ (.*)/ \(\1\)/\”: Novamente o grande monstro sed salva o dia. A regex que está ali pega o que vêm depois do espaço que está depois do * e imprime com parenteses em volta.
5. Muda a cor para branco, imprime $ (apenas para marcar o fim do prompt) e para de brincar com as cores do terminal, devolvendo o controle à shell.

A versão anterior que eu usava da PS1 usava ruby pra fazer essa mágica toda, mas dessa forma não depende mais do ruby instalado na máquina.

Posts Relacionados:

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

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.