GIT - for developers

Diego Pereira Grassato •dgrassato@ciandt.com

Utilitários
Um commit em um repositório git registra uma fotografia (snapshot) de
todos os arquivos no seu diretório. É como um grande copy&paste, mas
ainda melhor!

O Git tem por objetivo manter os commits tão leves quanto possível, de
forma que ele não copia cegamente o diretório completo toda vez que você
commita. Ele pode (quando possível) comprimir um commit como um
conjunto de mudanças (ou um "delta") entre uma versão do seu repositório e
a seguinte.
O Git também mantém um histórico de quando ocorreu cada commit. É por
isso que a maioria dos commits tem ancestrais acima de si -- que indicamos
usando setas na nossa visualização. Manter a história é ótimo para todos que
trabalham no projeto!

Há muito para aprender, mas por enquanto pense nos commits como
snapshots do seu projeto. Os commits são muito leves, e mudar de um para
outro é extremamente rápido!
 Regras de commit
Sempre usar ID do Jira para conseguirmos traquear o que está sendo feito e
futuramente poder usar em automatização.
- Trabalhando em uma subtask informar o ID da task pai e da task filha e na
descrição o que foi feito na taks filha

git commit -m "[JIRA ID(história)][JIRA

ID(filho)] Comentario sobre a tarefa"
 Apelo e puxada de orelha sobre commits

Usar mensagem descritiva. Já ouvi casos de gente escrevendo “não sei”, “tô
com sono”, “alterei” e barbaridades do tipo. Se você está interessado em
utilizar um VCS mostra que você já é bem grandinho para poder utilizar a
ferramenta de maneira decente, então faça um favor para os outros
desenvolvedores ou até para você mesmo e utilize uma mensagem que preste no
momento do commit!
 Fluxo de trabalho
Uma vez que você já tenha um repositório, basta começar a trabalhar, criando,
removendo e alterando arquivos. Quando quiser versionar, você irá usar os
seguintes comandos:

git add arquivo (para cada arquivo criado, removido ou alterado)

git add -A (para adicionar todos os arquivos, cuidado tenha ciência
do que foi feito)
git add . (para adicionar todos os arquivos do diretório corrente)

git commit -m "[JIRA ID(história)][JIRA ID(filho)]

Comentario sobre a tarefa"
Enviando automaticamente arquivos para a staging area

Vale notar a opção -a: ela indica que todos os arquivos que foram modificados
ou apagados devem ser automaticamente enviados para a staging area,
incluindo-os no commit.

git commit -am "[JIRA ID(história)][JIRA ID(filho)]

Comentario sobre a tarefa"
 Os Três Estados
É interessante você saber que, no jargão do Git, os arquivos estão sempre em um
de três estados:

Modified (modificado): são os arquivos que você criou,

removeu ou alterou.
Staged (observado, em tradução livre): são os arquivos
que serão versionados ao se fazer commit.
Commited (versionado, em tradução livre): são os
arquivos armazenados no repositório.
 Status
O comando git status permite que você veja o que está acontecendo a cada
momento:

git status
 Log
Uma vez que você já trabalhou um monte e fez um monte de commits, é
possível que você queira ver o histórico das suas alterações. E, para fazer isso,
basta executar o seguinte comando:

git log
git log -n 10

git log --stat

git log --oneline
 Show
Ele irá mostrar não só a mensagem do commit, mas o que exatamente você fez
nele, conforme o exemplo abaixo (copiado diretamente do meu terminal):

git show 7396e009a21fba5d7b9774a807

 diff
Se você possui arquivos na stage área, e quiser verificar suas modificações com
mais detalhes você pode usar o git diff, em vermelho aparecerá as mudanças
feitas:

git diff
 diff
Se você quiser ver as modificações entre dois commit:
git diff ..HEAD~1
 diff
Configurar o meld para melhorar a visualização diff e merge
$ sudo apt-get install meld -y

$ vi $HOME/.config/git_meld_diff.sh

#!/usr/bin/env bash
meld "$5" "$2"

$ git config --global merge.tool meld

$ git config --global diff.external /home/dgrassato/.config/git_meld_diff.sh
 reset
Utilizado para voltar versões:
git reset --hard HEAD~1

Voltará uma versão do no tempo, HEAD significa a

cabeça(raiz). Cuidado os arquivos serão perdidos.
HEAD~2 - volta duas versões

git reset --hard - limpará a staging

area(perderás todo seu trabalho)
 reset/diff
Se você quiser ver as modificações entre commites:

HEAD~2 # move dois atrás

HEAD~n # move N atrás
HEAD^ # move um atrás
HEAD^^ # move dois atrás Para poucos
commits, podemos utilizar ^, depois, ∼
 reset
Utilizado para voltar versões:
git reset --soft HEAD~1

Voltará uma versão do no tempo, porém será desfeito

somente o commit os arquivos ficaram disponíveis para
modificação e posteriormente commit.
 Removendo arquivos
Podemos remover arquivos do sistema de arquivos e do controle do VCS
utilizando o comando rm (do Git, não do sistema!). Lógico que seria bem fácil
fazer!:
echo "wawa" >> removed-files
git add .
git commit -m “Add new file”
rm removed-files
git add removed-files
git commit -m “Bye file”
 Removendo arquivos

Mas vamos supor que enviamos o arquivo removed-files para a área de

staging. Se tentarmos apagar o arquivo com git rm, vamos ter uma situação
como essa:
echo "wawa" >> removed-files
git add removed-files
git rm removed-files
 Removendo arquivos

O Git nos avisa que o arquivo está na área de staging, e para removê-lo vamos
precisar utilizar a opção -f:
git rm -f removed-files
Branches
Agora vamos utilizar um dos principais recursos do Git, a
criação (e também mudança, deleção) de branches.
Branches são ramos de desenvolvimento onde podemos
alterar nossos arquivos de modo que fiquem separados uns
dos outros, para que mais tarde possamos fundir o seu
conteúdo com outra outra branch, de por exemplo, código
de produção, ou apagar a branch se fizemos alguma coisa
que não ficou correta, sem alterar qualquer outro ponto.
Listando branches

git branch
O asterisco mostra qual é a branch corrente. Para mostrar quais são as branches
remotas (se houver alguma):

git branch -r
Listando todas as branches, inclusive remoto:

git branch -a
Deltando branches(-d ou --delete)

git branch -d feature/release-2015-02-03

Usando força bruta(--delete --force)

git branch -D feature/release-2015-02-03

Deletando remotamente
git push origin --delete feature/release-2015-02-03
cherry-pick
 cherry-pick

Cada commit em um repositório corresponde a uma tree cheia de arquivos.

Normalmente, esses arquivos foram criados ao longo de vários commits. Mas, às
vezes, é necessário levar o delta entre dois commits, e aplicá-lo a um branch
diferente.

Um caso comum em que isso ocorre é quando um problema foi identificado e

posteriormente corrigido, mas precisa portar para um branch de versão anterior.
 cherry-pick

Nesse caso, você não quer pegar o estado atual da tree (que pode ter alterações
inacabadas ou não testadas); você só quer pegar o delta associado a essa
mudança.

Em outros sistemas de controle de versão, você teria apenas que criar um diff
com base na mudança mais recente, e depois corrigir a mudança em seu branch
de lançamento. Em vez disso, com o Git, podemos usar o comando cherry-pick
para fazer o trabalho para nós:
 cherry-pick

git checkout -b feature/pick

Change a file:
git commit -am “Bugfix fixed”
git log #9606701fd4bfd8de41a71b6153c6e3b

git checkout master

git cherry-pick 9606701fd4bfd2746153c6e3b
Rewriting history
O principal trabalho do Git é garantir que você nunca perca uma alteração na
qual fez commit. Mas, ele também foi desenvolvido para dar a você o controle
total sobre seu fluxo de trabalho de desenvolvimento. Isto inclui deixar você
definir exatamente como o histórico do seu projeto aparecerá; no entanto, ele
também cria o potencial de perder commits. O Git fornece comandos de reescrita
de histórico sob o aviso de isenção de que usá-los pode resultar em perda de
conteúdo.
O Git possui vários mecanismos para armazenar seu histórico e salvar as
mudanças. Estes mecanismos incluem: commit --amend, git rebase e git
reflog. Estas opções dão a você opções poderosas de personalização do fluxo de
trabalho.
 Alterando o último commit

git commit --amend é uma forma conveniente de modificar o commit

mais recente. Ele permite que você combine alterações preparadas com o commit
anterior, em vez de criar um novo commit. Ele também pode ser usado simplesmente
para editar a mensagem do commit anterior sem alterar seu instantâneo. No entanto,
emendar não apenas altera o commit mais recente, ele o substitui totalmente, o que
significa que o commit emendado será uma nova entidade com sua própria
referência
 Alterando a mensagem mais recente de commit do Git
Digamos que nós editamos o que gostaríamos de realizar commit em um único
instantâneo, mas esquecemos de adicionar um dos arquivos da primeira vez. Corrigir
o erro é simplesmente uma questão de preparar o outro arquivo e fazer commit com
o sinalizador --amend:
git commit --amend
Adicionar a opção -m permite que você transmita uma nova mensagem para a linha
de comandos sem ser solicitado a abrir um editor.

git commit --amend -m "uma mensagem de

commit atualizada"
 Alterando arquivos com commit

O sinalizador --no-edit permitirá que você faça a emenda no seu commit sem alterar
a mensagem do commit dele.

echo “bbb”>> b.txt

git add b.txt

git commit --amend --no-edit

Stash
Muitas vezes, quando você está trabalhando em uma parte do seu projeto, as coisas
estão em um estado confuso e você quer mudar de branch por um tempo para
trabalhar em outra coisa. O problema é, você não quer fazer o commit de um
trabalho incompleto somente para voltar a ele mais tarde. A resposta para esse
problema é o comando git stash.

Fazer Stash é tirar o estado sujo do seu diretório de trabalho, isto é, seus arquivos
modificados que estão sendo rastreados e mudanças na área de seleção e o salva em
uma pilha de modificações inacabadas que você pode voltar a qualquer momento.
 - Adicionar arquivos no stash
git stash

- Lista areas de stash

git stash list
- Aplica a ultima area de stash
git stash apply

- Aplica uma determinada area de stash

git stash apply stash@{2}
- Limpa toda area de stash
git stash clear
Merge / Rebase
Squash
O comando squash’s é onde vemos a verdadeira utilidade do rebase. O squash
permite que você especifique quais commits deseja mesclar nos commits anteriores.
É isto que permite um "histórico limpo". Durante a reprodução de rebase, o Git
executará o comando especificado de rebase para cada commit. No caso de realizar
squash nos commits, o Git abrirá seu editor de texto configurado e solicitará que
você combine as mensagens especificadas de commit. Este processo inteiro pode ser
visualizado da seguinte forma:
Reflog
Logs de referência, ou "reflogs" são um mecanismo que o Git utiliza para registrar
as atualizações aplicadas a pontas de ramificações e outras referências de commit.
Um reflog permite que você volte a commits mesmo que eles são estejam
referenciados por nenhuma ramificação ou marca. Depois de reescrever o histórico,
o reflog contém informações sobre o estado antigo das ramificações e permite que
você volte àquele estado, se necessário. Toda vez que a ponta da sua ramificação for
atualizada por algum motivo (por trocar de ramificação, colocar novas alterações,
reescrever o histórico ou simplesmente adicionar novos commits), uma nova entrada
será adicionada ao reflog.
Blame
git blame <file>
Remote/Clone
Tags
Obrigado

ciandt.com
 CI&T ICON COLLECTION
PART 1
Combine ícones para Use todos os recursos: recorte, Explore mais: crie diagramas.
melhor representar a rotacione e crie composições.
sua ideia.
= = Entrega de
valor

+ = Crescimento
baseado Produto de
em dados excelência

Mente
+ = Focada

+ = + =