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