@matheusbsbs / matheus-bagliano / commits / e658002005
Fork 0

Translate the tutorial to Brazillian Portuguese

Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>

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