fournova

GIT CHEAT SHEET

presented by TOWER Version control with Git - made easy

CRIAR
Clona um repositrio existente
$ git clone ssh://user@domain.com/repo.git

Cria um novo repositrio local

$ git init

BRANCHES E TAGS
Lista todas as branches existentes
$ git branch -av

Muda a branch atual

$ git checkout <branch>

Cria uma branch a partir do HEAD atual

MODIFICAES LOCAIS
Arquivos modificados no diretrio ativo
$ git status

Modificaes em arquivos versionados

$ git diff

Add all current changes to the next commit

$ git add .

Adiciona as mudanas do <file>

no prximo commit
$ git add -p <file>

Commita todas as modificaes de

arquivos versionados
$ git commit -a

Commita modificaes preparadas

$ git commit

Modifica o ltimo commit

No modifique commits publicados!
$ git commit --amend

LINHA DO TEMPO
Mostra todos os commits, comeando
pelo mais novo
$ git log

Mostra as modificaes para um arquivo

especfico
$ git log -p <file>

Quem mudou o qu e quando em um arquivo

$ git blame <file>

$ git branch <new-branch>

Deleta uma branch local

$ git checkout --track <remote/branch>

Delete a local branch

$ git branch -d <branch>

Marca o commit atual com uma tag

$ git tag <tag-name>

ATUALIZAR E PUBLICAR
Lista todos os remotes configurados
atualmente

MERGE E REBASE
Fazer merge da <branch> no HEAD atual
$ git merge <branch>

Fazer rebase do seu HEAD na <branch>

No faa rebase com commits publicados!
$ git rebase <branch>

Abortar um rebase
$ git rebase --abort

Continuar um rebase depois de resolver

conflitos
$ git rebase --continue

Usar a sua ferramente de merge

configurada para resolver conflitos
$ git mergetool

Use seu editor para resolver conflitos manualmente e marcar o arquivo como resolvido
$ git add <resolved-file>
$ git rm <resolved-file>

$ git remote -v

Mostra informaes sobre um remote

$ git remote show <remote>

Adiciona um novo repositrio remoto,

nomeado <remote> 
$ git remote add <shortname> <url>

Baixa todas as modificaes do <remote>,

mas no integra ao HEAD
$ git fetch <remote>

Baixa as modificao e automaticamente

faz o merge
$ git pull <remote> <branch>

Publica as modificaes locais em um remote

$ git push <remote> <branch>

Deleta uma branch no remote

$ git branch -dr <remote/branch>

Publica suas tags

$ git push --tags

DESFAZER
Descarta todas as mudanas locais
no diretrio atual
$ git reset --hard HEAD

Descarta mudanas locais em

um arquivo especfico
$ git checkout HEAD <file>

Reverte um commit (criando um novo com as

modifies ao contrrio)
$ git revert <commit>

Reseta o ponteiro do HEAD para um

commit anterior
e descarta as modificaes desde ento
$ git reset --hard <commit>

e preserva todas as modificaes como

modificaes no preparadas
$ git reset <commit>

e preserva modificaes locais no commitadas

$ git reset --keep <commit>

30 Tage kostenlose Testversion unter

www.git-tower.com

Version control with Git - made easy

fournova

VERSION CONTROL
MELHORES PRTICAS

COMMITE MODIFICAES
RELACIONADAS
Um commit deve ser uma pacote de modificaes relacionadas. Por exemplo, corrigindo
dois bugs diferentes deve produzir dois commits separados. Pequenos commits tornam
fcil para outros desenvolvedores entenderem as modificaes e as desfazerem caso
algo saia errado.
Com ferramentas como rea de staging e a
habilidade de enviar para stage apenas partes
de um arquivo, o Git torna fcil a criao de
commits bem granulares.

COMMITE SEMPRE
Commitar com frequncia ajuda manter seus
commits pequenos e, novamente, ajuda voc
commitar apenas modificaes relacionadas.
Alm disso, isso permite voc compartilhar
seu cdigo mais frequentemente com os
outros. Dessa forma mais fcil para todos
integrarem as mudanas regularmente,
evitando clonfitos no merge. Tendo poucos
e grandes commits, e compartilhando-os
raramente, em contraste, torna a resoluo
de conflitos difcil.

NO COMMITE TRABALHO PELA METADE

Voc s deve commitar o cdigo quando ele
estiver pronto. Isso no significa que voc
deve completar um grande feature inteira
antes de commitar. Pelo contrrio: Divida a
implementao das features blocos lgicos e
lembre-se de commitar cedo e com frequncia. Mas no commite apenas para ter algo
no repositrio antes de deixar o escritrio do
final do dia. Se voc est tentado a commitar
apenas pela necessidade de uma cpia de
trabalho limpa (para fazer checkout em uma
branch, pull em modificaes, etc.) considere
usar a funcionalidade de stash do Git.

Teste grtis por 30 dias em

www.git-tower.com

TESTE O CDIGO ANTES DE COMMITAR

Resista a tentao de commitar algo que
voc acha que terminou. Teste completamente para ter certeza que est pronto e
no tem efeitos colaterais (as far as one can
tell). Enquanto que commitar coisas pela
metade, exige apenas que voc se perdoe, ter
seu cdigo testado muito mais importante
quando ele publicado/compartilhado com
seus amigos.

ESCREVA BOAS MENSAGENS DE COMMIT

Comece sua mensagem com um pequeno
sumrio de sua modificaes (at 50 letras
como orientao). Separe isso do corpo do
commit com uma linha em branco. O corpo da
mensagem deve prover respostas detalhadas
para as seguintes perguntas:
Qual foi a motivao para a modificao?
Quais as diferenas da ltima
implementao?
Use o imperativo, no tempo presente
(muda, no mudou ou mudanas) para
ser consistente com mensagens geradas a
partir de comandos como git merge.

CONTROLE DE VERSO NO BACKUP

Ter um backup dos seus arquivos em um
servidor remoto um bom efeito colateral do
uso de sistemas de controle de verso. Mas
voc no deveria usar um SCV como backup.
Fazendo o controle de verso, voc deve prestar ateno em commitar semanticamente no amontoe apenas um monte de arquivos.

USE BRANCHES
Branches so umas das funcionalidades
mais poderosas do Git - e no por acidente:
branchs de uma forma fcil e rpida foi um
requisito central desde o incio. Branches so
ferramentas perfeitas para ajudar voc a no
misturar diferentes frentes de desenvolvimento. Voc deve usar branches vrias vezes
no seu fluxo de desenvolvimento: para
novas funcionalidades, correes de bugs,
ideias...

SIGA UM WORKFLOW
O Git permite voc escolher entre vrias formas de desenvolvimento: branches de longa
durao, branches como tpicos, merge ou
rebase, git-flow...
A sua escolha depende de alguns fatores:
seus projeto, seu desenvolvimento global e
fluxo de deploy e (talvez o mais
importante) nas preferncias suas e do seu
time. Independente do que voc escolha,
apenas garanta que todos concordem em
seguir o fluxo de trabalho.

AJUDA E DOCUMENTAO
Obtenha ajuda por linha de comando
$ git help <command>

RECURSOS ONLINE GRTIS

http://www.git-tower.com/learn
http://rogerdudler.github.io/git-guide/
http://www.git-scm.org/

Version control with Git - made easy