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