Alberto Leal

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.

Cenário: Seu cliente utiliza um outro SCM, por exemplo, o Harvest, no projeto o qual você trabalha. Mas, você e sua equipe resolvem utilizar o Git. Eis que você faz uma série de scripts de automação para pegar o seu release no Git e entregá-lo ao Harvest. Bacana, não? Para que isso funcione perfeitamente, você deve passar para o sistema de automação o nome dos arquivos que foram alterados, desse jeito, não será necessário enviar arquivos que sequer sofreram modificações, o que é bem interessante, diga-se de passagem.

Legal, existe o comando git whatchanged. Você pode passa como parâmetro o total de commits que você deseja analisar, utilizando a opção -n. Se você omití-lo, todas as modificações serão exibidas. (Se você informar o parâmetro -p, serão exibidas as modificações dentro dos arquivos).

Vamos dar uma olhada na saída desse comando:

$ git whatchanged -n 3
commit 8d726556aec75e1d6ef5ae477532fcc11770ac01
Author: Alberto Leal
Date:   Wed Jun 3 16:04:23 2009 -0400
 
Message 3
 
:100755 000000 0615380... 0000000... D  workspace/xxx/yyy/cfgXPTO.jnlp
:100755 000000 37076cc... 0000000... D  workspace/xxx/yyy/packageXYZ.jar
 
commit 3ab3a5e95fa031d8eb93154d161bfba228bc5f86
Author: Alberto Leal
Date:   Wed Jun 3 15:38:00 2009 -0400
 
Message 2
 
:100755 100755 849dc69... 1e7ef9d... M  workspace/xxx/src/com/xxx/yyy/ModelXYZ.java
:100755 100755 9828364... d85e5ee... M  workspace/xxx/WebContent/WEB-INF/jsp/viewXYZ.jsp
:000000 100755 0000000... d034c28... A  workspace/xxx/WebContent/htmlXPTO.html
 
commit 7e076b5130340f28e57526cf71ce96d7cc279538
Author: Alberto Leal
Date:   Wed Jun 3 10:04:56 2009 -0400
 
Message 1
 
:100755 100755 9c322de... 9828364... M  workspace/xxx/WebContent/WEB-INF/jsp/anotherXTPO.jsp

Repare que se você quiser pegar os arquivos modificados, você terá que copiar um a um. Trabalhoso, não? Existem diversas maneiras de se recuperar apenas os nomes dos arquivos. Uma sugestão seria:

def files_changed(commits, last_commit)
  File.open(commits, "r") do |infile|
  infile.each_line do |line|
    if line.include? last_commit
      break
    else
      er = line.match(/workspace(.*)/)
      puts er unless er.nil?
    end
  end
  end
end
 
files_changed(ARGV[0], ARGV[1])

Execute o seguinte comando no seu terminal para obter o resultado desejado:

$ git whatchanged > files.txt && ruby files_changed.rb files.txt 7e076b513

Se você quiser, simplesmente, pegar todos os arquivos modificado, você pode executar o comando abaixo:

$ git whatchanged | grep workspace | awk '{print($6)}'

Fica aí mais uma dica. Afinal, seria bem chato ter que copiar arquivo por arquivo =)

Olá Pessoal,

Quando você utilizava o SVN ou CVS, provavelmente, você já utilizou ou ouviu falar do Tortoise. Agora, você já pode utilizá-lo junto com o Git.

Sua equipe utiliza Git na empresa? Você quer ver quem anda comitando mais?

Algumas pessoas me perguntaram como fazer para obter tal resultado. Há algum tempo eu twittei sobre isso.

Para aqueles que acompanham o meu blog, mas não me acompanham no twitter, aí vai a dica. A maneira de ver o total de commits de cada commiter em um projeto que utiliza o Git, como controlador de versão, é:

1

git shortlog -s -n --all

(O tweet está aqui.)

Ok. Mas agora você quer ver o total de commits apenas nos repositórios remotos? O comando é:

1

git rev-list --remotes --pretty=short

(O tweet está aqui.)

Cenário: Você trabalhou durante dias em um branch. Fez vários commits nele. E…., após algumas discussões, ficou decidido que algumas das suas modificações não entrarão na próxima build. A idéia das mensagens ao se fazer um commit é ajudar na identificação daquele commit específico.  Você pode analisar estas mensagens e remover alguns commits com base em tais mensagens. Mas, às vezes, só isso não basta para você. Você quer analisar antes alguns commits para ter certeza de que somente as alterações desejáveis, sejam adicionadas na build. Comando: git whatchanged Ps: As mensagens foram alteradas propositalmente. Utilize mensagens significativas em seus commits.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

commit d9a472455d9f91c75465af9778f5271baf532813
Author: Alberto Alvine <albertonb@gmail.com>
Date:   Thu May 28 14:14:39 2009 -0400
 
    Message 7
 
commit 6251f4b532d0c602e41742ab6399b637b14596c8
Author: Alberto Alvine <albertonb@gmail.com>
Date:   Wed May 27 15:51:56 2009 -0400
 
    Message 6
 
commit e71160c9fc1f676e94c4fe732f169e153731bf4c
Author: Alberto Alvine <albertonb@gmail.com>
Date:   Tue May 26 13:18:03 2009 -0400
 
    Message 5
 
commit e91d5a2171f8a4edcb60004967bad847339046d8
Author: Alberto Alvine <albertonb@gmail.com>
Date:   Thu May 21 15:31:49 2009 -0400
 
    Message 4
 
commit b514e967f01f579faab27f84017897d017810038
Author: Alberto Alvine <albertonb@gmail.com>
Date:   Thu May 21 10:23:50 2009 -0400
 
    Message 3
 
commit c59d02c18bfeff297f91fc2f06247e82ff77b741
Author: Alberto Alvine <albertonb@gmail.com>
Date:   Tue May 19 09:18:37 2009 -0400
 
    Message 2
 
commit 48b5d388ad78dbc260a3afd164c6b46cca7b9e51
Author: Alberto Alvine <albertonb@gmail.com>
Date:   Wed May 13 09:46:28 2009 -0400
 
    Message 1

Para visualizar quais foram as alterações em todos commits, execute git whatchanged -p. Esse comando mostrará os diffs de todos os arquivos que foram alterados. Se for desejável apenas visualizar os arquivos que sofreram alterações, execute apenas git whatchanged, sem parâmetro. Este comando foi útil para mim. Fica aí mais uma dica =) UPDATE 1: Esqueci de mencionar: Na hora de executar o git revert, você deve executá-lo de forma inversa, isto é,  vamos imaginar que você deseja desfazer os 2 últimos commits, o primeiro revert vai ser para o último commit, e o segundo revert para o penúltimo commit.

Dando sequência aos posts sobre GIT, aí vai mais uma dica: Como quebrar um commit e cancelar algumas alterações.

Assim como os posts anteriores, esse post foi inspirado em um problema que o meu time enfrentou semana passada.

Cenário: Foi feito o push de um commit contendo várias alterações no código. Porém, após ter sido feito o code review foi detectado que algumas mudanças não seriam mais necessárias, e/ou deveriam ser implementadas de outra forma. Claro que seria possível ir no código fonte e ir apagando todas as alterações que foram feitas. Mas, será que essa “limpeza” sairia às mil maravilhas? Será que o código voltaria a ficar da mesma forma que antes das alterações terem sido feitas? Acho difícil!

Elaborei um pequeno exemplo, apenas, para tentar ilustrar o cenário acima.

Temos os seguintes commits em nosso Projeto:

Repare que foi criado um branch para resolver um defeito, no nosso caso, foi adicionar um novo campo, País. Mas por algum motivo o registro de idade foi alterado acidentalmente.

No caso acima, é fácil ir ao arquivo e desfazer as alteração incorreta no campo “idade” antes de fazer o rebase/merge, eu sei. Mas, tente imaginar códigos reais, complexos, onde voltar ao código fonte e desfazer as alterações não seria a melhor solução =)

Uma solução para trazer todas as alterações e escolher o que vai ser efetivado para o merge/rebase é trazer o commit de volta para o stage do git para trabalhar nas alterações. Para isso, vamos utilizar o comando git format-patch para recuperar os commits. Em seguida, criaremos um novo branch para trabalharmos nas modificações e finalmente fazer o rebase com o branch master:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

Alberto:ProjectX Alberto$ git branch
* Defect123
  master
Alberto:ProjectX Alberto$ git status
# On branch master
nothing to commit (working directory clean)
 
Alberto:ProjectX Alberto$ git log
commit ea4f2953c305b0453fd20f27b3043ebf96d541df
Author: Alberto Leal <albertonb@gmail.com>
Date:   Sat May 23 15:42:16 2009 -0300
 
    Adding new fields
 
commit 656236111360762d92f9efacb05e27b5cd067a04
Author: Alberto Leal <albertonb@gmail.com>
Date:   Sat May 23 15:41:35 2009 -0300
 
    Some new changes
 
commit 131519b37c1d1415e962d6fd23d4058c93438870
Author: Alberto Leal <albertonb@gmail.com>
Date:   Sat May 23 15:40:40 2009 -0300
 
    Initial Commit
Alberto:ProjectX Alberto$ git format-patch master
0001-Some-new-changes.patch
0002-Adding-new-fields.patch

Repare que os patches foram gerados  a partir do Defect123 em relação ao branch master, ou seja, somente as diferenças entre eles.

Para escolher quais as modificações vão entrar para fazer o merge/rebase com o master, é necessário que se crie um novo branch a partir do master - limpo, sem as modicações de Defect123 e use o comando git apply para aplicar os patches no stage.  Agora que os patches com os últimos commits já foram gerados, chegou a hora de jogá-los novamente no stage:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

Alberto:ProjectX Alberto$ git checkout master
Switched to branch "master"
Alberto:ProjectX Alberto$ git checkout -b Defect123_Changes
Switched to a new branch "Defect123_Changes"
Alberto:ProjectX Alberto$ git apply 0001-Some-new-changes.patch
Alberto:ProjectX Alberto$ git apply 0002-Adding-new-fields.patch
Alberto:ProjectX Alberto$ git log
commit 131519b37c1d1415e962d6fd23d4058c93438870
Author: Alberto Leal <albertonb@gmail.com>
Date:   Sat May 23 15:40:40 2009 -0300
 
    Initial Commit
Alberto:ProjectX Alberto$ git status
# On branch Defect123_Changes
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#
#       modified:   config.txt
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       0001-Some-new-changes.patch
#       0002-Adding-new-fields.patch
no changes added to commit (use "git add" and/or "git commit -a")

Veja que o arquivo config.txt foi alterado. Agora, vamos adicionar as alterações para serem comitadas, mas para isso vamos utilizar o comando git add -p (similar ao add interativo):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

Alberto:ProjectX Alberto$ git add -p config.txt
diff --git a/config.txt b/config.txt
index ac82771..b36405c 100644
--- a/config.txt
+++ b/config.txt
@@ -1,6 +1,8 @@
 Nome: Alberto Leal
-email: albertonb@gmail.com
-idade: 24
+Email: albertonb@gmail.com
+Idade: 2423434
 Empresa: IBM
+Telefone: 12-1234-5678
+País: Brasil
 Sexo: Masculino
 Estado civil: solteiro
Stage this hunk [y/n/a/d/s/?]? s
Split into 2 hunks.
@@ -1,4 +1,4 @@
 Nome: Alberto Leal
-email: albertonb@gmail.com
-idade: 24
+Email: albertonb@gmail.com
+Idade: 2423434
 Empresa: IBM
Stage this hunk [y/n/a/d/j/J/?]? n
@@ -4,3 +4,5 @@
 Empresa: IBM
+Telefone: 12-1234-5678
+País: Brasil
 Sexo: Masculino
 Estado civil: solteiro
Stage this hunk [y/n/a/d/K/?]? y

Utilizando o comando acima, podemos quebrar as alterações feitas no arquivo utilizando a opção “s” (split). Após, você informa se deseja adicionar os fragmentos ao stage, utilizando as opções “y”- yes e “n”- no. Todos os fragmentos que você desejar adicionar no stage para comitá-lo, utilize a opção “y”. No pequeno exemplo acima, apenas foi mantido no commit a adição dos novos campos: Telefone e País. A alteração equivocada no campo “idade”foi eliminada do commit. Só nos resta efetivar as alterações comitando as mundanças:

1
2
3
4
5
6
7
8
9
10
11
12
13

Alberto:ProjectX Alberto$ git commit -m 'Cutting branch'
Created commit 9e365a2: Cutting branch
 1 files changed, 2 insertions(+), 0 deletions(-)
Alberto:ProjectX Alberto$ git checkout config.txt
Alberto:ProjectX Alberto$ cat config.txt
Nome: Alberto Leal
email: albertonb@gmail.com
idade: 24
Empresa: IBM
Telefone: 12-1234-5678
País: Brasil
Sexo: Masculino
Estado civil: solteiro

Cuidado para não adicionar o arquivo novamente ao stage (git add config.txt). As alterações que você fez já estão lá, prontas para serem comitadass. Se você se esquecer e adicionar o arquivo novamente ao stage, você perderá todas as mudanças que você fez no add interativo. É aconselhável que, logo após o comando git commit, você execute git checkout <file>, como mostrado acima. Desse jeito, você pegará o arquivo que está no repositório atualizado.

Agora, só nos resta fazer o rebase com o branch principal:

1
2
3
4
5

Alberto:ProjectX Alberto$ git checkout master
Switched to branch "master"
Alberto:ProjectX Alberto$ git rebase Defect123_Changes
First, rewinding head to replay your work on top of it...
Fast-forwarded master to Defect123_Changes.

É isso pessoal! Espero que a técnica apresentada nesse post lhe seja útil algum dia, assim como foi para mim.

Abraços!

Foi no ano passado que comecei a utilizar o GIT como VCS padrão. Naquela ocasião, não tinha  muitos problemas de conflitos, já que o “time” era pequeno - só eu =)

Hoje, faço parte de um time de 8 desenvolvedores. Já dá para imaginar que problemas na hora de fazer o rebase/merge já começam a aparecer com uma certa frequência. É gente comitando o dia inteiro!

Quando alguém no time cria um branch remoto, e trabalha nele o dia inteiro, por exemplo, ao final do dia é possível existir uma quantidade de commits consideráveis. Mas, na hora de enviar essas alterações para o repositório - git push - pode não ser necessário enviar todo aquele histórico de commits, apenas o resultado final interessa. Mas, dá para fazer isso? A resposta é: Sim, dá!

Mas atenção, somente faça isso em commits que ainda não foram enviados para o repositório externo. Pois se isso já tiver acontecido, outro desenvolvedor pode ter feito outras alterações e os conflitos aparecerão para lhe trazer dor de cabeça.

A idéia é utilizar git rebase –interactive, ou simplesmente git rebase -i.

Imagine o seguinte cenário: Você precisa trabalhar em um defect, e para isso você cria um branch para trabalhar nele. Ao longo do seu trabalho, você vai fazendo vários commits para manter o status do seu trabalho, já que de vez enquando você precisa pular para outro branch para resolver outra coisa, ou simplesmente testar alguma funcionalidade em outro branch que seu chefe lhe pediu (E, dependendo da situação, utilizar git stash não é a solução). Na hora de fazer o push, você só precisa enviar o defect resolvido. Se você desejar juntar todos os commits em um único commit que represente aquele seu defect, siga os passos abaixo:

Veja que temos 4 commits em nosso repositório. E desejamos unir os três últimos commits. Para isso, vamos utilizar o comando que foi citado anteriormente:

git rebase -i master~3

O comando acima diz para fazer o rebase interativo de 3 commits a partir do master. Feito isso, será aberto um editor para que você faça as devidas alterações:

Marque os últimos commits que você deseja juntar com o primeiro com a palavra squash. Feito isso, salve o documento e um novo editor será aberto para que você informe a mensagem para esse novo commit.  No exemplo abaixo, eu deixei as mensagens de todos os commits, mas é permitido que você informe a mensagem que desejar.

Observe que, agora temos apenas 2 commits, ao invés de 4:

Bastante útil. Mas, use apenas se você realmente não precisar do histórico desses commits.

UPDATE 1: Execute git rebase –continue para consolidar as alterações.