]> git.ipfire.org Git - thirdparty/git.git/blob - Documentation/pt_BR/gittutorial.txt
i18n: avoid parenthesized string as array initializer
[thirdparty/git.git] / Documentation / pt_BR / gittutorial.txt
1 gittutorial(7)
2 ==============
3
4 NOME
5 ----
6 gittutorial - Um tutorial de introdução ao git (para versão 1.5.1 ou mais nova)
7
8 SINOPSE
9 --------
10 git *
11
12 DESCRIÇÃO
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 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].
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 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 é:
42
43 ------------------------------------------------
44 $ git config --global user.name "Seu Nome Vem Aqui"
45 $ git config --global user.email voce@seudominio.exemplo.com
46 ------------------------------------------------
47
48
49 Importando um novo projeto
50 -----------------------
51
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:
54
55 ------------------------------------------------
56 $ tar xzf project.tar.gz
57 $ cd project
58 $ git init
59 ------------------------------------------------
60
61 Git irá responder
62
63 ------------------------------------------------
64 Initialized empty Git repository in .git/
65 ------------------------------------------------
66
67 Agora que você iniciou seu diretório de trabalho, você deve ter notado que um
68 novo diretório foi criado com o nome de ".git".
69
70 A seguir, diga ao git para gravar um instantâneo do conteúdo de todos os
71 arquivos sob o diretório atual (note o '.'), com 'git-add':
72
73 ------------------------------------------------
74 $ git add .
75 ------------------------------------------------
76
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':
80
81 ------------------------------------------------
82 $ git commit
83 ------------------------------------------------
84
85 Isto vai te pedir por uma mensagem de commit. Você agora gravou sua
86 primeira versão de seu projeto no git.
87
88 Fazendo mudanças
89 --------------
90
91 Modifique alguns arquivos, e, então, adicione seu conteúdo atualizado ao
92 índice:
93
94 ------------------------------------------------
95 $ git add file1 file2 file3
96 ------------------------------------------------
97
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:
100
101 ------------------------------------------------
102 $ git diff --cached
103 ------------------------------------------------
104
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':
108
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 ------------------------------------------------
120
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:
124
125 ------------------------------------------------
126 $ git commit
127 ------------------------------------------------
128
129 Ao executar esse comando, ele irá te pedir uma mensagem descrevendo a mudança,
130 e, então, irá gravar a nova versão do projeto.
131
132 Alternativamente, ao invés de executar 'git-add' antes, você pode usar
133
134 ------------------------------------------------
135 $ git commit -a
136 ------------------------------------------------
137
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.
140
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.
147
148 Git rastreia conteúdo, não arquivos
149 ----------------------------
150
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.
157
158 Visualizando a história do projeto
159 -----------------------
160
161 Em qualquer ponto você pode visualizar a história das suas mudanças
162 usando
163
164 ------------------------------------------------
165 $ git log
166 ------------------------------------------------
167
168 Se você também quiser ver a diferença completa a cada passo, use
169
170 ------------------------------------------------
171 $ git log -p
172 ------------------------------------------------
173
174 Geralmente, uma visão geral da mudança é útil para ter a sensação de
175 cada passo
176
177 ------------------------------------------------
178 $ git log --stat --summary
179 ------------------------------------------------
180
181 Gerenciando "branches"/ramos
182 -----------------
183
184 Um simples repositório git pode manter múltiplos ramos de
185 desenvolvimento. Para criar um novo ramo chamado "experimental", use
186
187 ------------------------------------------------
188 $ git branch experimental
189 ------------------------------------------------
190
191 Se você executar agora
192
193 ------------------------------------------------
194 $ git branch
195 ------------------------------------------------
196
197 você vai obter uma lista de todos os ramos existentes:
198
199 ------------------------------------------------
200 experimental
201 * master
202 ------------------------------------------------
203
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
207
208 ------------------------------------------------
209 $ git checkout experimental
210 ------------------------------------------------
211
212 para mudar para o ramo experimental. Agora edite um arquivo, grave a
213 mudança, e mude de volta para o ramo master:
214
215 ------------------------------------------------
216 (edita arquivo)
217 $ git commit -a
218 $ git checkout master
219 ------------------------------------------------
220
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.
223
224 Você pode fazer uma mudança diferente no ramo master:
225
226 ------------------------------------------------
227 (edit file)
228 $ git commit -a
229 ------------------------------------------------
230
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
234
235 ------------------------------------------------
236 $ git merge experimental
237 ------------------------------------------------
238
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;
242
243 ------------------------------------------------
244 $ git diff
245 ------------------------------------------------
246
247 vai exibir isto. Após você editar os arquivos para resolver os
248 conflitos,
249
250 ------------------------------------------------
251 $ git commit -a
252 ------------------------------------------------
253
254 irá gravar o resultado da unificação. Finalmente,
255
256 ------------------------------------------------
257 $ gitk
258 ------------------------------------------------
259
260 vai mostrar uma bela representação gráfica da história resultante.
261
262 Neste ponto você pode remover seu ramo experimental com
263
264 ------------------------------------------------
265 $ git branch -d experimental
266 ------------------------------------------------
267
268 Este comando garante que as mudanças no ramo experimental já estão no
269 ramo atual.
270
271 Se você desenvolve em um ramo ideia-louca, e se arrepende, você pode
272 sempre remover o ramo com
273
274 -------------------------------------
275 $ git branch -D ideia-louca
276 -------------------------------------
277
278 Ramos são baratos e fáceis, então isto é uma boa maneira de experimentar
279 alguma coisa.
280
281 Usando git para colaboração
282 ---------------------------
283
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.
287
288 Bob começa com:
289
290 ------------------------------------------------
291 bob$ git clone /home/alice/project myrepo
292 ------------------------------------------------
293
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.
297
298 Bob então faz algumas mudanças e as grava:
299
300 ------------------------------------------------
301 (editar arquivos)
302 bob$ git commit -a
303 (repetir conforme necessário)
304 ------------------------------------------------
305
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:
308
309 ------------------------------------------------
310 alice$ cd /home/alice/project
311 alice$ git pull /home/bob/myrepo master
312 ------------------------------------------------
313
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.)
318
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.
321
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).
330
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:
335
336 ------------------------------------------------
337 alice$ git fetch /home/bob/myrepo master
338 alice$ git log -p HEAD..FETCH_HEAD
339 ------------------------------------------------
340
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.
346
347 Se Alice quer visualizar o que Bob fez desde que suas histórias se
348 ramificaram, ela pode disparar o seguinte comando:
349
350 ------------------------------------------------
351 $ gitk HEAD..FETCH_HEAD
352 ------------------------------------------------
353
354 Isto usa a mesma notação de intervalo que vimos antes com 'git log'.
355
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:
358
359 ------------------------------------------------
360 $ gitk HEAD...FETCH_HEAD
361 ------------------------------------------------
362
363 Isto significa "mostre tudo que é alcançável de qualquer um deles, mas
364 exclua tudo que é alcançável a partir de ambos".
365
366 Por favor, note que essas notações de intervalo podem ser usadas tanto
367 com gitk quanto com "git log".
368
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.
375
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:
379
380 ------------------------------------------------
381 alice$ git remote add bob /home/bob/myrepo
382 ------------------------------------------------
383
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:
387
388 -------------------------------------
389 alice$ git fetch bob
390 -------------------------------------
391
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:
395
396 -------------------------------------
397 alice$ git log -p master..bob/master
398 -------------------------------------
399
400 mostra uma lista de todas as mudanças que Bob fez desde que ramificou do
401 ramo master de Alice.
402
403 Após examinar essas mudanças, Alice pode unificá-las em seu ramo master:
404
405 -------------------------------------
406 alice$ git merge bob/master
407 -------------------------------------
408
409 Esse `merge` pode também ser feito puxando de seu próprio ramo remoto,
410 assim:
411
412 -------------------------------------
413 alice$ git pull . remotes/bob/master
414 -------------------------------------
415
416 Note que 'git pull' sempre unifica ao ramo atual, independente do que
417 mais foi passado na linha de comando.
418
419 Depois, Bob pode atualizar seu repositório com as últimas mudanças de
420 Alice, usando
421
422 -------------------------------------
423 bob$ git pull
424 -------------------------------------
425
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:
430
431 -------------------------------------
432 bob$ git config --get remote.origin.url
433 /home/alice/project
434 -------------------------------------
435
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.)
439
440 Git também mantém uma cópia limpa do ramo master de Alice sob o nome
441 "origin/master":
442
443 -------------------------------------
444 bob$ git branch -r
445 origin/master
446 -------------------------------------
447
448 Se Bob decidir depois em trabalhar em um host diferente, ele ainda pode
449 executar clones e puxar usando o protocolo ssh:
450
451 -------------------------------------
452 bob$ git clone alice.org:/home/alice/project myrepo
453 -------------------------------------
454
455 Alternativamente, o git tem um protocolo nativo, ou pode usar rsync ou
456 http; veja linkgit:git-pull[1] para detalhes.
457
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].
461
462 Explorando história
463 -----------------
464
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:
469
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
475
476 merge-base: Clarify the comments on post processing.
477 -------------------------------------
478
479 Nós podemos dar este nome ao 'git-show' para ver os detalhes sobre este
480 commit.
481
482 -------------------------------------
483 $ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
484 -------------------------------------
485
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:
489
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 -------------------------------------
496
497 Todo commit normalmente tem um commit "pai" que aponta para o estado
498 anterior do projeto:
499
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 -------------------------------------
505
506 Note que commits de unificação podem ter mais de um pai:
507
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 -------------------------------------
512
513 Você também pode dar aos commits nomes à sua escolha; após executar
514
515 -------------------------------------
516 $ git tag v2.5 1b2e1d63ff
517 -------------------------------------
518
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.
523
524 Qualquer comando git que precise conhecer um commit pode receber
525 quaisquer desses nomes. Por exemplo:
526
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 -------------------------------------
534
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.
543
544 O comando 'git-grep' pode buscar strings em qualquer versão de seu
545 projeto, então
546
547 -------------------------------------
548 $ git grep "hello" v2.5
549 -------------------------------------
550
551 procura por todas as ocorrências de "hello" em v2.5.
552
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
555
556 -------------------------------------
557 $ git grep "hello"
558 -------------------------------------
559
560 é uma forma rápida de buscar somente os arquivos que são rastreados pelo
561 git.
562
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':
565
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 -------------------------------------
573
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
578
579 -------------------------------------
580 $ git log stable..master
581 -------------------------------------
582
583 irá listar os commits feitos no ramo "master" mas não no ramo
584 "stable", enquanto
585
586 -------------------------------------
587 $ git log master..stable
588 -------------------------------------
589
590 irá listar a lista de commits feitos no ramo "stable" mas não no ramo
591 "master".
592
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.
597
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,
601
602 -------------------------------------
603 $ gitk --since="2 weeks ago" drivers/
604 -------------------------------------
605
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 "+".)
610
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:
614
615 -------------------------------------
616 $ git diff v2.5:Makefile HEAD:Makefile.in
617 -------------------------------------
618
619 Você pode usar 'git-show' para ver tal arquivo:
620
621 -------------------------------------
622 $ git show v2.5:Makefile
623 -------------------------------------
624
625 Próximos passos
626 ----------
627
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:
632
633 * A base de objetos é um sistema bem elegante usado para armazenar a
634 história de seu projeto--arquivos, diretórios, e commits.
635
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.
639
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].
643
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:
646
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.
651
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.
658
659 * link:everyday.html[GIT diariamente com 20 e tantos comandos]
660
661 * linkgit:gitcvs-migration[7]: Git para usuários de CVS.
662
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]
672
673 GIT
674 ---
675 Parte da suite linkgit:git[1].