Cheat Sheet

CRIAR BRANCHES E TAGS MERGE E REBASE

Clona um repositório existente Lista todas as branches existentes Fazer merge da <branch> no HEAD atual
$ git clone ssh://user@domain.com/repo.git $ git branch -av $ git merge <branch>

Cria um novo repositório local Muda a branch atual Fazer rebase do seu HEAD na <branch>
Não faça rebase com commits publicados!
$ git init $ git checkout <branch>
$ git rebase <branch>
Cria uma branch a partir do HEAD atual
MODIFICAÇÕES LOCAIS
$ git branch <new-branch> Abortar um rebase
Arquivos modificados no diretório ativo $ git rebase --abort
Cria uma nova branch com base em uma
$ git status
branch remoto Continuarum rebase depois de resolver
Modificações em arquivos versionados $ git checkout --track <remote/branch> conflitos
$ git diff $ git rebase --continue
Delete a local branch
Adiciona todas as mudanças no próximo $ git branch -d <branch> Usar a sua ferramente de merge
commit configurada para resolver conflitos
Marca o commit atual com uma tag
$ git add . $ git mergetool
$ git tag <tag-name>
Adiciona as mudanças do <file> Use seu editor para resolver conflitos manual
no próximo commit ATUALIZAR E PUBLICAR mente e marcar o arquivo como resolvido
$ git add -p <file> Lista todos os remotes configurados $ git add <resolved-file>

$ git remote -v
Faz commit de todas as modificações de $ git rm <resolved-file>
arquivos versionados Mostra informações sobre um remote
$ git commit -a $ git remote show <remote> DESFAZER
Faz commit das modificações preparada Adiciona um novo repositório remoto, Descarta todas as mudanças locais
nomeado <remote> no diretório atual
$ git commit

$ git remote add <shortname> <url> $ git reset --hard HEAD

Modifica o último commit
Não modifique commits publicados! Descarta mudanças locais em
Baixa todas as modificações do <remote>,
$ git commit --amend mas não integra ao HEAD um arquivo específico

$ git fetch <remote> $ git checkout HEAD <file>

LINHA DO TEMPO
Mostra todos os commits, começando
pelo mais novo
$ git log
Desenha um gráfico ASCII representando
a estrutura de ramificação do histórico
$ git log --graph
Mostra as modificações para um arquivo
Baixa as modificação e automaticamente
faz o merge
$ git pull <remote> <branch>
Publica as modificações locais em um remote
$ git push <remote> <branch>
Deleta uma branch no remote
$ git branch -dr <remote/branch>
Reverte um commit (criando um novo com as
modifições ao contrário)
$ git revert <commit>
Reseta o ponteiro do HEAD para um
commit anterior
…e descarta as modificações desde então
$ git reset --hard <commit>

específico …e preserva todas as modificações como

Publica suas tags modificações não preparadas
$ git log -p <file>
$ git push --tags $ git reset <commit>
Quem mudou o quê e quando em um arquivo
SALVAR FRAGMENTOS …e preserva modificações locais não commitadas
$ git blame <file>
Armazena os arquivos rastreados $ git reset --keep <commit>

$ git stash

Restaura os arquivos em stash

$ git stash apply

FAÇA COMMIT DE MODIFICAÇÕES
RELACIONADAS
Um commit deve ser uma pacote de
modificações relacionadas. Por exemplo,
corrigindo dois bugs diferentes deve produzir
dois commits separados. Pequenos commits
tornam fácil para outros desenvolvedores
entenderem as modificações e as
desfazerem caso algo saia errado.
Separe novas implementações de mudanças
de refatoramento, assim, quem irá revisar o
código saberá qual commit verificar e qual
não realiza mudanças funcionais no código.
FAÇA COMMIT SEMPRE
Fazer commit com frequência ajuda a
manter seus commits pequenos e,
novamente, ajuda você a fazer commit
apenas de modificações relacionadas. Além
disso, permite compartilhar seu código mais
frequentemente com os outros, sendo mais
fácil para todos integrarem suas mudanças
regularmente, evitando conflitos no merge.
Se há uma pequena alteração que deveria
ter sido incorporada no commit anterior e
esse commit ainda não foi enviado para o
remote, utilize o amend do git para
incorporar as mudanças a serem feitas com
o último commit.
NÃO FAÇA COMMIT DE TRABALHO
PELA METADE
Você só deve fazer commit do código quando
ele estiver pronto. Isso não significa que você
deve completar uma grande feature inteira
antes de fazer commit. Pelo contrário: Divida
a implementação das features em blocos
lógicos e lembre-se de fazer commit cedo e
com frequência.
Se você quer fazer commit apenas pela
necessidade de uma cópia limpa (para fazer
checkout em uma branch, pull em
modificações, etc.) utilize o comando stash
do Git.
Adaptação do Cheat Sheet
disponibilizado pela Git Tower
Boas Práticas
TESTE O CÓDIGO ANTES DE
FAZER COMMIT
Evite fazer commit de algo que você «acha» que
terminou. Faça testes (de preferência de
unidade) para ter certeza que está pronto e não
tem efeitos colaterais . Ter seu código testado é
muito mais importante quando ele é
compartilhado com seus amigos, sem falar que
previne o trabalho de ter que realizar essa
correção no futuro, quando a equipe de QA
realizar os testes.
ESCREVA BOAS MENSAGENS DE COMMIT
Comece sua mensagem com um pequeno
resumo de sua modificações (até 50 letras
como orientação). Separe isso do corpo do
commit com uma linha em branco. O corpo
da mensagem deve prover respostas
detalhadas para as seguintes perguntas:
 O que foifeito?
 Como foi feito?
 Porque foi feito?
Use o imperativo, no tempo presente
(«muda», não «mudou» ou «mudanças»)
para ser consistente com mensagens
geradas a partir de comandos como git
merge.
MANTENHA O CÓDIGO ATUALIZADO
Manter sempre o repositório local atualizado
com o repositório remoto, e vice-versa, com
as alterações feitas pela equipe reduz
conflitos e previne bugs futuros. Faça sempre
pull do repositório aliado aos commits
frequentes.
USE BRANCHES
Branches são umas das funcionalidades
mais poderosas do Git - e não é por acidente:
branchs de uma forma fácil e rápida foi um
requisito central desde o início.
Em um projeto de longa duração, muitos
branches são criados e seus propósitos
podem ser confusos, por isso é importante
seguir um padrão de nomenclatura:
<tipo de branch>/<task>_<descrição>
Ex: feature/55_novoLayout
SIGA O WORKFLOW
O Git permite você escolher entre várias
formas de desenvolvimento: branches de
longa duração, branches como tópicos,
merge ou rebase, git-flow...
O git-flow é um modelo de branches que
consiste basicamente em manter os
branches master e develop durante todo o
desenvolvimento, com o develop sendo
integrado ao master quando necessário e
com branches de feature que se integram ao
develop na medida em que são finalizadas.
AJUDA E DOCUMENTAÇÃO
Obtenha ajuda por linha de comando
$ git help <command>