| blob | 81e7ad7df4d4f7e2dc2e1f31109f28b3b9627860 |
1 gittutorial(7)
2 ==============
4 NAME
5 ----
6 gittutorial - Um tutorial de introdução ao git (para versão 1.5.1 ou mais nova)
8 SYNOPSIS
9 --------
10 git *
12 DESCRIPTION
13 -----------
15 Este tutorial explica como importar um novo projeto para o git,
16 adicionar mudanças a ele, e compartilhar mudanças com outros
17 desenvolvedores.
19 Se, ao invés disso, você está interessado primariamente em usar git para
20 obter um projeto, por exemplo, para testar a última versão, você pode
21 preferir começar com os primeiros dois capítulos de
22 link:user-manual.html[O Manual do Usuário Git].
24 Primeiro, note que você pode obter documentação para um comando como
25 `git log --graph` com:
27 ------------------------------------------------
28 $ man git-log
29 ------------------------------------------------
31 ou:
33 ------------------------------------------------
34 $ git help log
35 ------------------------------------------------
37 Com a última forma, você pode usar o visualizador de manual de sua
38 escolha; veja linkgit:git-help[1] para maior informação.
40 É uma boa idéia informar ao git seu nome e endereço público de email
41 antes de fazer qualquer operação. A maneira mais fácil de fazê-lo é:
43 ------------------------------------------------
44 $ git config --global user.name "Seu Nome Vem Aqui"
45 $ git config --global user.email voce@seudominio.exemplo.com
46 ------------------------------------------------
49 Importando um novo projeto
50 -----------------------
52 Assuma que você tem um tarball project.tar.gz com seu trabalho inicial.
53 Você pode colocá-lo sob controle de revisão git da seguinte forma:
55 ------------------------------------------------
56 $ tar xzf project.tar.gz
57 $ cd project
58 $ git init
59 ------------------------------------------------
61 Git irá responder
63 ------------------------------------------------
64 Initialized empty Git repository in .git/
65 ------------------------------------------------
67 Você agora iniciou seu diretório de trabalho--você deve ter notado um
68 novo diretório criado, com o nome de ".git".
70 A seguir, diga ao git para gravar um instantâneo do conteúdo de todos os
71 arquivos sob o diretório corrente (note o '.'), com 'git-add':
73 ------------------------------------------------
74 $ git add .
75 ------------------------------------------------
77 Este instantâneo está agora armazenado em uma área temporária que o git
78 chama de "index" ou índice. Você pode armazenar permanentemente o
79 conteúdo do índice no repositório com 'git-commit':
81 ------------------------------------------------
82 $ git commit
83 ------------------------------------------------
85 Isto vai te pedir por uma mensagem de commit. Você agora gravou sua
86 primeira versão de seu projeto no git.
88 Fazendo mudanças
89 --------------
91 Modifique alguns arquivos, e, então, adicione seu conteúdo atualizado ao
92 índice:
94 ------------------------------------------------
95 $ git add file1 file2 file3
96 ------------------------------------------------
98 Você está agora pronto para fazer o commit. Você pode ver o que está
99 para ser gravado usando 'git-diff' com a opção --cached:
101 ------------------------------------------------
102 $ git diff --cached
103 ------------------------------------------------
105 (Sem --cached, o comando 'git-diff' irá te mostrar quaisquer mudanças
106 que você tenha feito mas ainda não adicionou ao índice.) Você também
107 pode obter um breve sumário da situação com 'git-status':
109 ------------------------------------------------
110 $ git status
111 # On branch master
112 # Changes to be committed:
113 # (use "git reset HEAD <file>..." to unstage)
114 #
115 # modified: file1
116 # modified: file2
117 # modified: file3
118 #
119 ------------------------------------------------
121 Se você precisar fazer qualquer outro ajuste, faça-o agora, e, então,
122 adicione qualquer conteúdo modificado ao índice. Finalmente, grave suas
123 mudanças com:
125 ------------------------------------------------
126 $ git commit
127 ------------------------------------------------
129 Isto irá novamente te pedir por uma mensagem descrevendo a mudança, e,
130 então, gravar a nova versão do projeto.
132 Alternativamente, ao invés de executar 'git-add' antes, você pode usar
134 ------------------------------------------------
135 $ git commit -a
136 ------------------------------------------------
138 o que irá automaticamente notar quaisquer arquivos modificados (mas não
139 novos), adicioná-los ao índices, e gravar, tudo em um único passo.
141 Uma nota em mensagens de commit: Apesar de não ser exigido, é uma boa
142 idéia começar a mensagem com uma simples e curta (menos de 50
143 caracteres) linha sumarizando a mudança, seguida de uma linha em branco
144 e, então, uma descrição mais detalhada. Ferramentas que transformam
145 commits em email, por exemplo, usam a primeira linha no campo de
146 cabeçalho Subject: e o resto no corpo.
148 Git rastreia conteúdo, não arquivos
149 ----------------------------
151 Muitos sistemas de controle de revisão provêem um comando `add` que diz
152 ao sistema para começar a rastrear mudanças em um novo arquivo. O
153 comando `add` do git faz algo mais simples e mais poderoso: 'git-add' é
154 usado tanto para arquivos novos e arquivos recentemente modificados, e
155 em ambos os casos, ele tira o instantâneo dos arquivos dados e armazena
156 o conteúdo no índice, pronto para inclusão do próximo commit.
158 Visualizando história do projeto
159 -----------------------
161 Em qualquer ponto você pode visualizar a história das suas mudanças
162 usando
164 ------------------------------------------------
165 $ git log
166 ------------------------------------------------
168 Se você também quer ver a diferença completa a cada passo, use
170 ------------------------------------------------
171 $ git log -p
172 ------------------------------------------------
174 Geralmente, uma visão geral da mudança é útil para ter a sensação de
175 cada passo
177 ------------------------------------------------
178 $ git log --stat --summary
179 ------------------------------------------------
181 Gerenciando "branches"/ramos
182 -----------------
184 Um simples repositório git pode manter múltiplos ramos de
185 desenvolvimento. Para criar um novo ramo chamado "experimental", use
187 ------------------------------------------------
188 $ git branch experimental
189 ------------------------------------------------
191 Se você executar agora
193 ------------------------------------------------
194 $ git branch
195 ------------------------------------------------
197 você vai obter uma lista de todos os ramos existentes:
199 ------------------------------------------------
200 experimental
201 * master
202 ------------------------------------------------
204 O ramo "experimental" é o que você acaba de criar, e o ramo "master" é o
205 ramo padrão que foi criado pra você automaticamente. O asterisco marca
206 o ramo em que você está atualmente; digite
208 ------------------------------------------------
209 $ git checkout experimental
210 ------------------------------------------------
212 para mudar para o ramo experimental. Agora edite um arquivo, grave a
213 mudança, e mude de volta para o ramo master:
215 ------------------------------------------------
216 (edita arquivo)
217 $ git commit -a
218 $ git checkout master
219 ------------------------------------------------
221 Verifique que a mudança que você fez não está mais visível, já que ela
222 foi feita no ramo experimental e você está de volta ao ramo master.
224 Você pode fazer uma mudança diferente no ramo master:
226 ------------------------------------------------
227 (edit file)
228 $ git commit -a
229 ------------------------------------------------
231 neste ponto, os dois ramos divergiram, com diferentes mudanças feitas em
232 cada um. Para unificar as mudanças feitas no experimental para o
233 master, execute
235 ------------------------------------------------
236 $ git merge experimental
237 ------------------------------------------------
239 Se as mudanças não conflitarem, estará pronto. Se existirem conflitos,
240 marcadores serão deixados nos arquivos problemáticos exibindo o
241 conflito;
243 ------------------------------------------------
244 $ git diff
245 ------------------------------------------------
247 vai exibir isto. Após você editar os arquivos para resolver os
248 conflitos,
250 ------------------------------------------------
251 $ git commit -a
252 ------------------------------------------------
254 irá gravar o resultado da unificação. Finalmente,
256 ------------------------------------------------
257 $ gitk
258 ------------------------------------------------
260 vai mostrar uma bela representação gráfica da história resultante.
262 Neste ponto você pode remover seu ramo experimental com
264 ------------------------------------------------
265 $ git branch -d experimental
266 ------------------------------------------------
268 Este comando garante que as mudanças no ramo experimental já estão no
269 ramo atual.
271 Se você desenvolve em um ramo ideia-louca, e se arrepende, você pode
272 sempre remover o ramo com
274 -------------------------------------
275 $ git branch -D ideia-louca
276 -------------------------------------
278 Ramos são baratos e fáceis, então isto é uma boa maneira de experimentar
279 alguma coisa.
281 Usando git para colaboração
282 ---------------------------
284 Suponha que Alice começou um novo projeto com um repositório git em
285 /home/alice/project, e que Bob, que tem um diretório home na mesma
286 máquina, quer contribuir.
288 Bob começa com:
290 ------------------------------------------------
291 bob$ git clone /home/alice/project myrepo
292 ------------------------------------------------
294 Isso cria um novo diretório "myrepo" contendo um clone do repositório de
295 Alice. O clone está no mesmo pé que o projeto original, possuindo sua
296 própria cópia da história do projeto original.
298 Bob então faz algumas mudanças e as grava:
300 ------------------------------------------------
301 (editar arquivos)
302 bob$ git commit -a
303 (repetir conforme necessário)
304 ------------------------------------------------
306 Quanto está pronto, ele diz a Alice para puxar as mudanças do
307 repositório em /home/bob/myrepo. Ela o faz com:
309 ------------------------------------------------
310 alice$ cd /home/alice/project
311 alice$ git pull /home/bob/myrepo master
312 ------------------------------------------------
314 Isto unifica as mudanças do ramo "master" do Bob ao ramo atual de Alice.
315 Se Alice fez suas próprias mudanças no intervalo, ela, então, pode
316 precisar corrigir manualmente quaisquer conflitos. (Note que o argumento
317 "master" no comando acima é, de fato, desnecessário, já que é o padrão.)
319 O comando "pull" executa, então, duas operações: ele obtém mudanças de
320 um ramo remoto, e, então, as unifica no ramo atual.
322 Note que, em geral, Alice gostaria que suas mudanças locais fossem
323 gravadas antes de iniciar este "pull". Se o trabalho de Bob conflita
324 com o que Alice fez desde que suas histórias se ramificaram, Alice irá
325 usar seu diretório de trabalho e o índice para resolver conflitos, e
326 mudanças locais existentes irão interferir com o processo de resolução
327 de conflitos (git ainda irá realizar a obtenção mas irá se recusar a
328 unificar --- Alice terá que se livrar de suas mudanças locais de alguma
329 forma e puxar de novo quando isso acontecer).
331 Alice pode espiar o que Bob fez sem unificar primeiro, usando o comando
332 "fetch"; isto permite Alice inspecionar o que Bob fez, usando um símbolo
333 especial "FETCH_HEAD", com o fim de determinar se ele tem alguma coisa
334 que vale puxar, assim:
336 ------------------------------------------------
337 alice$ git fetch /home/bob/myrepo master
338 alice$ git log -p HEAD..FETCH_HEAD
339 ------------------------------------------------
341 Esta operação é segura mesmo se Alice tem mudanças locais não gravadas.
342 A notação de intervalo "HEAD..FETCH_HEAD" significa mostrar tudo que é
343 alcançável de FETCH_HEAD mas exclua tudo o que é alcançável de HEAD.
344 Alice já sabe tudo que leva a seu estado atual (HEAD), e revisa o que Bob
345 tem em seu estado (FETCH_HEAD) que ela ainda não viu com esse comando.
347 Se Alice quer visualizar o que Bob fez desde que suas histórias se
348 ramificaram, ela pode disparar o seguinte comando:
350 ------------------------------------------------
351 $ gitk HEAD..FETCH_HEAD
352 ------------------------------------------------
354 Isto usa a mesma notação de intervalo que vimos antes com 'git log'.
356 Alice pode querer ver o que ambos fizeram desde que ramificaram. Ela
357 pode usar a forma com três pontos ao invés da forma com dois pontos:
359 ------------------------------------------------
360 $ gitk HEAD...FETCH_HEAD
361 ------------------------------------------------
363 Isto significa "mostre tudo que é alcançável de qualquer um deles, mas
364 exclua tudo que é alcançável a partir de ambos".
366 Por favor, note que essas notações de intervalo podem ser usadas tanto
367 com gitk quanto com "git log".
369 Após inspecionar o que Bob fez, se não há nada urgente, Alice pode
370 decidir continuar trabalhando sem puxar de Bob. Se a história de Bob
371 tem alguma coisa que Alice precisa imediatamente, Alice pode optar por
372 separar seu trabalho em progresso primeiro, fazer um "pull", e, então,
373 finalmente, retomar seu trabalho em progresso em cima da história
374 resultante.
376 Quando você está trabalhando em um pequeno grupo unido, não é incomum
377 interagir com o mesmo repositório várias e várias vezes. Definindo um
378 repositório remoto antes de tudo, você pode fazê-lo mais facilmente:
380 ------------------------------------------------
381 alice$ git remote add bob /home/bob/myrepo
382 ------------------------------------------------
384 Com isso, Alice pode executar a primeira parte da operação "pull" usando
385 o comando 'git-fetch' sem unificar suas mudanças com seu próprio ramo,
386 usando:
388 -------------------------------------
389 alice$ git fetch bob
390 -------------------------------------
392 Diferente da forma longa, quando Alice obteve de Bob usando um
393 repositório remoto antes definido com 'git-remote', o que foi obtido é
394 armazenado em um ramo remoto, neste caso `bob/master`. Então, após isso:
396 -------------------------------------
397 alice$ git log -p master..bob/master
398 -------------------------------------
400 mostra uma lista de todas as mudanças que Bob fez desde que ramificou do
401 ramo master de Alice.
403 Após examinar essas mudanças, Alice pode unificá-las em seu ramo master:
405 -------------------------------------
406 alice$ git merge bob/master
407 -------------------------------------
409 Esse `merge` pode também ser feito puxando de seu próprio ramo remoto,
410 assim:
412 -------------------------------------
413 alice$ git pull . remotes/bob/master
414 -------------------------------------
416 Note que 'git pull' sempre unifica ao ramo atual, independente do que
417 mais foi passado na linha de comando.
419 Depois, Bob pode atualizar seu repositório com as últimas mudanças de
420 Alice, usando
422 -------------------------------------
423 bob$ git pull
424 -------------------------------------
426 Note que ele não precisa dar o caminho do repositório de Alice; quando
427 Bob clonou seu repositório, o git armazenou a localização de seu
428 repositório na configuração do mesmo, e essa localização é usada
429 para puxar:
431 -------------------------------------
432 bob$ git config --get remote.origin.url
433 /home/alice/project
434 -------------------------------------
436 (A configuração completa criada por 'git-clone' é visível usando `git
437 config -l`, e a página de manual linkgit:git-config[1] explica o
438 significado de cada opção.)
440 Git também mantém uma cópia limpa do ramo master de Alice sob o nome
441 "origin/master":
443 -------------------------------------
444 bob$ git branch -r
445 origin/master
446 -------------------------------------
448 Se Bob decidir depois em trabalhar em um host diferente, ele ainda pode
449 executar clones e puxar usando o protocolo ssh:
451 -------------------------------------
452 bob$ git clone alice.org:/home/alice/project myrepo
453 -------------------------------------
455 Alternativamente, o git tem um protocolo nativo, ou pode usar rsync ou
456 http; veja linkgit:git-pull[1] para detalhes.
458 Git pode também ser usado em um modo parecido com CVS, com um
459 repositório central para o qual vários usuários empurram modificações;
460 veja linkgit:git-push[1] e linkgit:gitcvs-migration[7].
462 Explorando história
463 -----------------
465 A história no git é representada como uma série de commits
466 interrelacionados. Nós já vimos que o comando 'git-log' pode listar
467 esses commits. Note que a primeira linha de cada entrada no log também
468 dá o nome para o commit:
470 -------------------------------------
471 $ git log
472 commit c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
473 Author: Junio C Hamano <junkio@cox.net>
474 Date: Tue May 16 17:18:22 2006 -0700
476 merge-base: Clarify the comments on post processing.
477 -------------------------------------
479 Nós podemos dar este nome ao 'git-show' para ver os detalhes sobre este
480 commit.
482 -------------------------------------
483 $ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
484 -------------------------------------
486 Mas há outras formas de se referir aos commits. Você pode usar qualquer
487 parte inicial do nome que seja longo o bastante para identificar
488 unicamente o commit:
490 -------------------------------------
491 $ git show c82a22c39c # os primeiros caracteres do nome são o bastante
492 # usualmente
493 $ git show HEAD # a ponta do ramo atual
494 $ git show experimental # a ponta do ramo "experimental"
495 -------------------------------------
497 Todo commit normalmente tem um commit "pai" que aponta para o estado
498 anterior do projeto:
500 -------------------------------------
501 $ git show HEAD^ # para ver o pai de HEAD
502 $ git show HEAD^^ # para ver o avô de HEAD
503 $ git show HEAD~4 # para ver o trisavô de HEAD
504 -------------------------------------
506 Note que commits de unificação podem ter mais de um pai:
508 -------------------------------------
509 $ git show HEAD^1 # mostra o primeiro pai de HEAD (o mesmo que HEAD^)
510 $ git show HEAD^2 # mostra o segundo pai de HEAD
511 -------------------------------------
513 Você também pode dar aos commits nomes à sua escolha; após executar
515 -------------------------------------
516 $ git tag v2.5 1b2e1d63ff
517 -------------------------------------
519 você pode se referir a 1b2e1d63ff pelo nome "v2.5". Se você pretende
520 compartilhar esse nome com outras pessoas (por exemplo, para identificar
521 uma versão de lançamento), você deveria criar um objeto "tag", e talvez
522 assiná-lo; veja linkgit:git-tag[1] para detalhes.
524 Qualquer comando git que precise conhecer um commit pode receber
525 quaisquer desses nomes. Por exemplo:
527 -------------------------------------
528 $ git diff v2.5 HEAD # compara o HEAD atual com v2.5
529 $ git branch stable v2.5 # inicia um novo ramo chamado "stable" baseado
530 # em v2.5
531 $ git reset --hard HEAD^ # reseta seu ramo atual e seu diretório de
532 # trabalho a seu estado em HEAD^
533 -------------------------------------
535 Seja cuidadoso com o último comando: além de perder quaisquer mudanças
536 em seu diretório de trabalho, ele também remove todos os commits
537 posteriores desse ramo. Se esse ramo é o único ramo contendo esses
538 commits, eles serão perdidos. Também, não use 'git-reset' num ramo
539 publicamente visível de onde outros desenvolvedores puxam, já que vai
540 forçar unificações desnecessárias para que outros desenvolvedores limpem
541 a história. Se você precisa desfazer mudanças que você empurrou, use
542 'git-revert' no lugar.
544 O comando 'git-grep' pode buscar strings em qualquer versão de seu
545 projeto, então
547 -------------------------------------
548 $ git grep "hello" v2.5
549 -------------------------------------
551 procura por todas as ocorrências de "hello" em v2.5.
553 Se você deixar de fora o nome do commit, 'git-grep' irá procurar
554 quaisquer dos arquivos que ele gerencia no diretório corrente. Então
556 -------------------------------------
557 $ git grep "hello"
558 -------------------------------------
560 é uma forma rápida de buscar somente os arquivos que são rastreados pelo
561 git.
563 Muitos comandos git também recebem um conjunto de commits, o que pode
564 ser especificado de várias formas. Aqui estão alguns exemplos com 'git-log':
566 -------------------------------------
567 $ git log v2.5..v2.6 # commits entre v2.5 e v2.6
568 $ git log v2.5.. # commits desde v2.5
569 $ git log --since="2 weeks ago" # commits das últimas 2 semanas
570 $ git log v2.5.. Makefile # commits desde v2.5 que modificam
571 # Makefile
572 -------------------------------------
574 Você também pode dar ao 'git-log' um "intervalo" de commits onde o
575 primeiro não é necessariamente um ancestral do segundo; por exemplo, se
576 as pontas dos ramos "stable" e "master" divergiram de um commit
577 comum algum tempo atrás, então
579 -------------------------------------
580 $ git log stable..master
581 -------------------------------------
583 irá listar os commits feitos no ramo "master" mas não no ramo
584 "stable", enquanto
586 -------------------------------------
587 $ git log master..stable
588 -------------------------------------
590 irá listar a lista de commits feitos no ramo "stable" mas não no ramo
591 "master".
593 O comando 'git-log' tem uma fraqueza: ele precisa mostrar os commits em
594 uma lista. Quando a história tem linhas de desenvolvimento que
595 divergiram e então foram unificadas novamente, a ordem em que 'git-log'
596 apresenta essas mudanças é irrelevante.
598 A maioria dos projetos com múltiplos contribuidores (como o kernel
599 Linux, ou o próprio git) tem unificações frequentes, e 'gitk' faz um
600 trabalho melhor de visualizar sua história. Por exemplo,
602 -------------------------------------
603 $ gitk --since="2 weeks ago" drivers/
604 -------------------------------------
606 permite a você navegar em quaisquer commits desde as últimas duas semanas
607 de commits que modificaram arquivos sob o diretório "drivers". (Nota:
608 você pode ajustar as fontes do gitk segurando a tecla control enquanto
609 pressiona "-" ou "+".)
611 Finalmente, a maioria dos comandos que recebem nomes de arquivo permitirão
612 também, opcionalmente, preceder qualquer nome de arquivo por um
613 commit, para especificar uma versão particular do arquivo:
615 -------------------------------------
616 $ git diff v2.5:Makefile HEAD:Makefile.in
617 -------------------------------------
619 Você pode usar 'git-show' para ver tal arquivo:
621 -------------------------------------
622 $ git show v2.5:Makefile
623 -------------------------------------
625 Próximos passos
626 ----------
628 Este tutorial deve ser o bastante para operar controle de revisão
629 distribuído básico para seus projetos. No entanto, para entender
630 plenamente a profundidade e o poder do git você precisa entender duas
631 idéias simples nas quais ele se baseia:
633 * A base de objetos é um sistema bem elegante usado para armazenar a
634 história de seu projeto--arquivos, diretórios, e commits.
636 * O arquivo de índice é um cache do estado de uma árvore de diretório,
637 usado para criar commits, restaurar diretórios de trabalho, e
638 armazenar as várias árvores envolvidas em uma unificação.
640 A parte dois deste tutorial explica a base de objetos, o arquivo de
641 índice, e algumas outras coisinhas que você vai precisar pra usar o
642 máximo do git. Você pode encontrá-la em linkgit:gittutorial-2[7].
644 Se você não quiser continuar com o tutorial agora nesse momento, algumas
645 outras digressões que podem ser interessantes neste ponto são:
647 * linkgit:git-format-patch[1], linkgit:git-am[1]: Estes convertem
648 séries de commits em patches para email, e vice-versa, úteis para
649 projetos como o kernel Linux que dependem fortemente de patches
650 enviados por email.
652 * linkgit:git-bisect[1]: Quando há uma regressão em seu projeto, uma
653 forma de rastrear um bug é procurando pela história para encontrar o
654 commit culpado. Git bisect pode ajudar a executar uma busca binária
655 por esse commit. Ele é inteligente o bastante para executar uma
656 busca próxima da ótima mesmo no caso de uma história complexa
657 não-linear com muitos ramos unificados.
659 * link:everyday.html[GIT diariamente com 20 e tantos comandos]
661 * linkgit:gitcvs-migration[7]: Git para usuários de CVS.
663 VEJA TAMBÉM
664 --------
665 linkgit:gittutorial-2[7],
666 linkgit:gitcvs-migration[7],
667 linkgit:gitcore-tutorial[7],
668 linkgit:gitglossary[7],
669 linkgit:git-help[1],
670 link:everyday.html[git diariamente],
671 link:user-manual.html[O Manual do Usuário git]
673 GIT
674 ---
675 Parte da suite linkgit:git[1].