{"thread":{"id":"32466","subject":"[PATCH] Remove Documentation/pt_BR/gittutorial.txt","startedAt":"2012-12-27T14:15:52Z","lastAt":"2012-12-27T14:15:52Z","messageCount":1,"participants":["Thomas Ackermann"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"205552","messageId":"912689493.1321768.1356617752157.JavaMail.ngmail@webmail17.arcor-online.net","threadId":"32466","inReplyTo":null,"subject":"[PATCH] Remove Documentation/pt_BR/gittutorial.txt","fromName":"Thomas Ackermann","fromEmail":"th.acker@arcor.de","sentAt":"2012-12-27T14:15:52Z","receivedAt":"2012-12-27T14:15:52Z","isPatch":true,"sender":{"key":"th.acker@arcor.de","avatar":"https://avatars.githubusercontent.com/u/1358536?v=4"},"body":"\nThis file is rather outdated and IMHO shouldn't be there in the first place.\n(If there are translations of the Git documentation they are better be kept\nseparate from the original documentation.)\n\nSigned-off-by: Thomas Ackermann <th.acker@arcor.de>\n---\n Documentation/pt_BR/gittutorial.txt | 675 ------------------------------------\n 1 file changed, 675 deletions(-)\n delete mode 100644 Documentation/pt_BR/gittutorial.txt\n\ndiff --git a/Documentation/pt_BR/gittutorial.txt b/Documentation/pt_BR/gittutorial.txt\ndeleted file mode 100644\nindex beba065..0000000\n--- a/Documentation/pt_BR/gittutorial.txt\n+++ /dev/null\n@@ -1,675 +0,0 @@\n-gittutorial(7)\n-==============\n-\n-NOME\n-----\n-gittutorial - Um tutorial de introdução ao git (para versão 1.5.1 ou mais nova)\n-\n-SINOPSE\n---------\n-git *\n-\n-DESCRIÇÃO\n------------\n-\n-Este tutorial explica como importar um novo projeto para o git,\n-adicionar mudanças a ele, e compartilhar mudanças com outros\n-desenvolvedores.\n-\n-Se, ao invés disso, você está interessado primariamente em usar git para\n-obter um projeto, por exemplo, para testar a última versão, você pode\n-preferir começar com os primeiros dois capítulos de\n-link:user-manual.html[O Manual do Usuário Git].\n-\n-Primeiro, note que você pode obter documentação para um comando como\n-`git log --graph` com:\n-\n-------------------------------------------------\n-$ man git-log\n-------------------------------------------------\n-\n-ou:\n-\n-------------------------------------------------\n-$ git help log\n-------------------------------------------------\n-\n-Com a última forma, você pode usar o visualizador de manual de sua\n-escolha; veja linkgit:git-help[1] para maior informação.\n-\n-É uma boa idéia informar ao git seu nome e endereço público de email\n-antes de fazer qualquer operação. A maneira mais fácil de fazê-lo é:\n-\n-------------------------------------------------\n-$ git config --global user.name \"Seu Nome Vem Aqui\"\n-$ git config --global user.email voce@seudominio.exemplo.com\n-------------------------------------------------\n-\n-\n-Importando um novo projeto\n------------------------\n-\n-Assuma que você tem um tarball project.tar.gz com seu trabalho inicial.\n-Você pode colocá-lo sob controle de revisão git da seguinte forma:\n-\n-------------------------------------------------\n-$ tar xzf project.tar.gz\n-$ cd project\n-$ git init\n-------------------------------------------------\n-\n-Git irá responder\n-\n-------------------------------------------------\n-Initialized empty Git repository in .git/\n-------------------------------------------------\n-\n-Agora que você iniciou seu diretório de trabalho, você deve ter notado que um\n-novo diretório foi criado com o nome de \".git\".\n-\n-A seguir, diga ao git para gravar um instantâneo do conteúdo de todos os\n-arquivos sob o diretório atual (note o '.'), com 'git-add':\n-\n-------------------------------------------------\n-$ git add .\n-------------------------------------------------\n-\n-Este instantâneo está agora armazenado em uma área temporária que o git\n-chama de \"index\" ou índice. Você pode armazenar permanentemente o\n-conteúdo do índice no repositório com 'git-commit':\n-\n-------------------------------------------------\n-$ git commit\n-------------------------------------------------\n-\n-Isto vai te pedir por uma mensagem de commit. Você agora gravou sua\n-primeira versão de seu projeto no git.\n-\n-Fazendo mudanças\n---------------\n-\n-Modifique alguns arquivos, e, então, adicione seu conteúdo atualizado ao\n-índice:\n-\n-------------------------------------------------\n-$ git add file1 file2 file3\n-------------------------------------------------\n-\n-Você está agora pronto para fazer o commit. Você pode ver o que está\n-para ser gravado usando 'git-diff' com a opção --cached:\n-\n-------------------------------------------------\n-$ git diff --cached\n-------------------------------------------------\n-\n-(Sem --cached, o comando 'git-diff' irá te mostrar quaisquer mudanças\n-que você tenha feito mas ainda não adicionou ao índice.) Você também\n-pode obter um breve sumário da situação com 'git-status':\n-\n-------------------------------------------------\n-$ git status\n-# On branch master\n-# Changes to be committed:\n-#   (use \"git reset HEAD <file>...\" to unstage)\n-#\n-#\tmodified:   file1\n-#\tmodified:   file2\n-#\tmodified:   file3\n-#\n-------------------------------------------------\n-\n-Se você precisar fazer qualquer outro ajuste, faça-o agora, e, então,\n-adicione qualquer conteúdo modificado ao índice. Finalmente, grave suas\n-mudanças com:\n-\n-------------------------------------------------\n-$ git commit\n-------------------------------------------------\n-\n-Ao executar esse comando, ele irá te pedir uma mensagem descrevendo a mudança,\n-e, então, irá gravar a nova versão do projeto.\n-\n-Alternativamente, ao invés de executar 'git-add' antes, você pode usar\n-\n-------------------------------------------------\n-$ git commit -a\n-------------------------------------------------\n-\n-o que irá automaticamente notar quaisquer arquivos modificados (mas não\n-novos), adicioná-los ao índices, e gravar, tudo em um único passo.\n-\n-Uma nota em mensagens de commit: Apesar de não ser exigido, é uma boa\n-idéia começar a mensagem com uma simples e curta (menos de 50\n-caracteres) linha sumarizando a mudança, seguida de uma linha em branco\n-e, então, uma descrição mais detalhada. Ferramentas que transformam\n-commits em email, por exemplo, usam a primeira linha no campo de\n-cabeçalho \"Subject:\" e o resto no corpo.\n-\n-Git rastreia conteúdo, não arquivos\n-----------------------------\n-\n-Muitos sistemas de controle de revisão provêem um comando `add` que diz\n-ao sistema para começar a rastrear mudanças em um novo arquivo. O\n-comando `add` do git faz algo mais simples e mais poderoso: 'git-add' é\n-usado tanto para arquivos novos e arquivos recentemente modificados, e\n-em ambos os casos, ele tira o instantâneo dos arquivos dados e armazena\n-o conteúdo no índice, pronto para inclusão do próximo commit.\n-\n-Visualizando a história do projeto\n------------------------\n-\n-Em qualquer ponto você pode visualizar a história das suas mudanças\n-usando\n-\n-------------------------------------------------\n-$ git log\n-------------------------------------------------\n-\n-Se você também quiser ver a diferença completa a cada passo, use\n-\n-------------------------------------------------\n-$ git log -p\n-------------------------------------------------\n-\n-Geralmente, uma visão geral da mudança é útil para ter a sensação de\n-cada passo\n-\n-------------------------------------------------\n-$ git log --stat --summary\n-------------------------------------------------\n-\n-Gerenciando \"branches\"/ramos\n------------------\n-\n-Um simples repositório git pode manter múltiplos ramos de\n-desenvolvimento. Para criar um novo ramo chamado \"experimental\", use\n-\n-------------------------------------------------\n-$ git branch experimental\n-------------------------------------------------\n-\n-Se você executar agora\n-\n-------------------------------------------------\n-$ git branch\n-------------------------------------------------\n-\n-você vai obter uma lista de todos os ramos existentes:\n-\n-------------------------------------------------\n-  experimental\n-* master\n-------------------------------------------------\n-\n-O ramo \"experimental\" é o que você acaba de criar, e o ramo \"master\" é o\n-ramo padrão que foi criado pra você automaticamente. O asterisco marca\n-o ramo em que você está atualmente; digite\n-\n-------------------------------------------------\n-$ git checkout experimental\n-------------------------------------------------\n-\n-para mudar para o ramo experimental. Agora edite um arquivo, grave a\n-mudança, e mude de volta para o ramo master:\n-\n-------------------------------------------------\n-(edita arquivo)\n-$ git commit -a\n-$ git checkout master\n-------------------------------------------------\n-\n-Verifique que a mudança que você fez não está mais visível, já que ela\n-foi feita no ramo experimental e você está de volta ao ramo master.\n-\n-Você pode fazer uma mudança diferente no ramo master:\n-\n-------------------------------------------------\n-(edit file)\n-$ git commit -a\n-------------------------------------------------\n-\n-neste ponto, os dois ramos divergiram, com diferentes mudanças feitas em\n-cada um. Para unificar as mudanças feitas no experimental para o\n-master, execute\n-\n-------------------------------------------------\n-$ git merge experimental\n-------------------------------------------------\n-\n-Se as mudanças não conflitarem, estará pronto. Se existirem conflitos,\n-marcadores serão deixados nos arquivos problemáticos exibindo o\n-conflito;\n-\n-------------------------------------------------\n-$ git diff\n-------------------------------------------------\n-\n-vai exibir isto. Após você editar os arquivos para resolver os\n-conflitos,\n-\n-------------------------------------------------\n-$ git commit -a\n-------------------------------------------------\n-\n-irá gravar o resultado da unificação. Finalmente,\n-\n-------------------------------------------------\n-$ gitk\n-------------------------------------------------\n-\n-vai mostrar uma bela representação gráfica da história resultante.\n-\n-Neste ponto você pode remover seu ramo experimental com\n-\n-------------------------------------------------\n-$ git branch -d experimental\n-------------------------------------------------\n-\n-Este comando garante que as mudanças no ramo experimental já estão no\n-ramo atual.\n-\n-Se você desenvolve em um ramo ideia-louca, e se arrepende, você pode\n-sempre remover o ramo com\n-\n--------------------------------------\n-$ git branch -D ideia-louca\n--------------------------------------\n-\n-Ramos são baratos e fáceis, então isto é uma boa maneira de experimentar\n-alguma coisa.\n-\n-Usando git para colaboração\n----------------------------\n-\n-Suponha que Alice começou um novo projeto com um repositório git em\n-/home/alice/project, e que Bob, que tem um diretório home na mesma\n-máquina, quer contribuir.\n-\n-Bob começa com:\n-\n-------------------------------------------------\n-bob$ git clone /home/alice/project myrepo\n-------------------------------------------------\n-\n-Isso cria um novo diretório \"myrepo\" contendo um clone do repositório de\n-Alice. O clone está no mesmo pé que o projeto original, possuindo sua\n-própria cópia da história do projeto original.\n-\n-Bob então faz algumas mudanças e as grava:\n-\n-------------------------------------------------\n-(editar arquivos)\n-bob$ git commit -a\n-(repetir conforme necessário)\n-------------------------------------------------\n-\n-Quanto está pronto, ele diz a Alice para puxar as mudanças do\n-repositório em /home/bob/myrepo. Ela o faz com:\n-\n-------------------------------------------------\n-alice$ cd /home/alice/project\n-alice$ git pull /home/bob/myrepo master\n-------------------------------------------------\n-\n-Isto unifica as mudanças do ramo \"master\" do Bob ao ramo atual de Alice.\n-Se Alice fez suas próprias mudanças no intervalo, ela, então, pode\n-precisar corrigir manualmente quaisquer conflitos. (Note que o argumento\n-\"master\" no comando acima é, de fato, desnecessário, já que é o padrão.)\n-\n-O comando \"pull\" executa, então, duas operações: ele obtém mudanças de\n-um ramo remoto, e, então, as unifica no ramo atual.\n-\n-Note que, em geral, Alice gostaria que suas mudanças locais fossem\n-gravadas antes de iniciar este \"pull\". Se o trabalho de Bob conflita\n-com o que Alice fez desde que suas histórias se ramificaram, Alice irá\n-usar seu diretório de trabalho e o índice para resolver conflitos, e\n-mudanças locais existentes irão interferir com o processo de resolução\n-de conflitos (git ainda irá realizar a obtenção mas irá se recusar a\n-unificar --- Alice terá que se livrar de suas mudanças locais de alguma\n-forma e puxar de novo quando isso acontecer).\n-\n-Alice pode espiar o que Bob fez sem unificar primeiro, usando o comando\n-\"fetch\"; isto permite Alice inspecionar o que Bob fez, usando um símbolo\n-especial \"FETCH_HEAD\", com o fim de determinar se ele tem alguma coisa\n-que vale puxar, assim:\n-\n-------------------------------------------------\n-alice$ git fetch /home/bob/myrepo master\n-alice$ git log -p HEAD..FETCH_HEAD\n-------------------------------------------------\n-\n-Esta operação é segura mesmo se Alice tem mudanças locais não gravadas.\n-A notação de intervalo \"HEAD..FETCH_HEAD\" significa mostrar tudo que é\n-alcançável de FETCH_HEAD mas exclua tudo o que é alcançável de HEAD.\n-Alice já sabe tudo que leva a seu estado atual (HEAD), e revisa o que Bob\n-tem em seu estado (FETCH_HEAD) que ela ainda não viu com esse comando.\n-\n-Se Alice quer visualizar o que Bob fez desde que suas histórias se\n-ramificaram, ela pode disparar o seguinte comando:\n-\n-------------------------------------------------\n-$ gitk HEAD..FETCH_HEAD\n-------------------------------------------------\n-\n-Isto usa a mesma notação de intervalo que vimos antes com 'git log'.\n-\n-Alice pode querer ver o que ambos fizeram desde que ramificaram. Ela\n-pode usar a forma com três pontos ao invés da forma com dois pontos:\n-\n-------------------------------------------------\n-$ gitk HEAD...FETCH_HEAD\n-------------------------------------------------\n-\n-Isto significa \"mostre tudo que é alcançável de qualquer um deles, mas\n-exclua tudo que é alcançável a partir de ambos\".\n-\n-Por favor, note que essas notações de intervalo podem ser usadas tanto\n-com gitk quanto com \"git log\".\n-\n-Após inspecionar o que Bob fez, se não há nada urgente, Alice pode\n-decidir continuar trabalhando sem puxar de Bob. Se a história de Bob\n-tem alguma coisa que Alice precisa imediatamente, Alice pode optar por\n-separar seu trabalho em progresso primeiro, fazer um \"pull\", e, então,\n-finalmente, retomar seu trabalho em progresso em cima da história\n-resultante.\n-\n-Quando você está trabalhando em um pequeno grupo unido, não é incomum\n-interagir com o mesmo repositório várias e várias vezes. Definindo um\n-repositório remoto antes de tudo, você pode fazê-lo mais facilmente:\n-\n-------------------------------------------------\n-alice$ git remote add bob /home/bob/myrepo\n-------------------------------------------------\n-\n-Com isso, Alice pode executar a primeira parte da operação \"pull\" usando\n-o comando 'git-fetch' sem unificar suas mudanças com seu próprio ramo,\n-usando:\n-\n--------------------------------------\n-alice$ git fetch bob\n--------------------------------------\n-\n-Diferente da forma longa, quando Alice obteve de Bob usando um\n-repositório remoto antes definido com 'git-remote', o que foi obtido é\n-armazenado em um ramo remoto, neste caso `bob/master`. Então, após isso:\n-\n--------------------------------------\n-alice$ git log -p master..bob/master\n--------------------------------------\n-\n-mostra uma lista de todas as mudanças que Bob fez desde que ramificou do\n-ramo master de Alice.\n-\n-Após examinar essas mudanças, Alice pode unificá-las em seu ramo master:\n-\n--------------------------------------\n-alice$ git merge bob/master\n--------------------------------------\n-\n-Esse `merge` pode também ser feito puxando de seu próprio ramo remoto,\n-assim:\n-\n--------------------------------------\n-alice$ git pull . remotes/bob/master\n--------------------------------------\n-\n-Note que 'git pull' sempre unifica ao ramo atual, independente do que\n-mais foi passado na linha de comando.\n-\n-Depois, Bob pode atualizar seu repositório com as últimas mudanças de\n-Alice, usando\n-\n--------------------------------------\n-bob$ git pull\n--------------------------------------\n-\n-Note que ele não precisa dar o caminho do repositório de Alice; quando\n-Bob clonou seu repositório, o git armazenou a localização de seu\n-repositório na configuração do mesmo, e essa localização é usada\n-para puxar:\n-\n--------------------------------------\n-bob$ git config --get remote.origin.url\n-/home/alice/project\n--------------------------------------\n-\n-(A configuração completa criada por 'git-clone' é visível usando `git\n-config -l`, e a página de manual linkgit:git-config[1] explica o\n-significado de cada opção.)\n-\n-Git também mantém uma cópia limpa do ramo master de Alice sob o nome\n-\"origin/master\":\n-\n--------------------------------------\n-bob$ git branch -r\n-  origin/master\n--------------------------------------\n-\n-Se Bob decidir depois em trabalhar em um host diferente, ele ainda pode\n-executar clones e puxar usando o protocolo ssh:\n-\n--------------------------------------\n-bob$ git clone alice.org:/home/alice/project myrepo\n--------------------------------------\n-\n-Alternativamente, o git tem um protocolo nativo, ou pode usar rsync ou\n-http; veja linkgit:git-pull[1] para detalhes.\n-\n-Git pode também ser usado em um modo parecido com CVS, com um\n-repositório central para o qual vários usuários empurram modificações;\n-veja linkgit:git-push[1] e linkgit:gitcvs-migration[7].\n-\n-Explorando história\n------------------\n-\n-A história no git é representada como uma série de commits\n-interrelacionados. Nós já vimos que o comando 'git-log' pode listar\n-esses commits. Note que a primeira linha de cada entrada no log também\n-dá o nome para o commit:\n-\n--------------------------------------\n-$ git log\n-commit c82a22c39cbc32576f64f5c6b3f24b99ea8149c7\n-Author: Junio C Hamano <junkio@cox.net>\n-Date:   Tue May 16 17:18:22 2006 -0700\n-\n-    merge-base: Clarify the comments on post processing.\n--------------------------------------\n-\n-Nós podemos dar este nome ao 'git-show' para ver os detalhes sobre este\n-commit.\n-\n--------------------------------------\n-$ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7\n--------------------------------------\n-\n-Mas há outras formas de se referir aos commits. Você pode usar qualquer\n-parte inicial do nome que seja longo o bastante para identificar\n-unicamente o commit:\n-\n--------------------------------------\n-$ git show c82a22c39c\t# os primeiros caracteres do nome são o bastante\n-\t\t\t# usualmente\n-$ git show HEAD\t\t# a ponta do ramo atual\n-$ git show experimental\t# a ponta do ramo \"experimental\"\n--------------------------------------\n-\n-Todo commit normalmente tem um commit \"pai\" que aponta para o estado\n-anterior do projeto:\n-\n--------------------------------------\n-$ git show HEAD^  # para ver o pai de HEAD\n-$ git show HEAD^^ # para ver o avô de HEAD\n-$ git show HEAD~4 # para ver o trisavô de HEAD\n--------------------------------------\n-\n-Note que commits de unificação podem ter mais de um pai:\n-\n--------------------------------------\n-$ git show HEAD^1 # mostra o primeiro pai de HEAD (o mesmo que HEAD^)\n-$ git show HEAD^2 # mostra o segundo pai de HEAD\n--------------------------------------\n-\n-Você também pode dar aos commits nomes à sua escolha; após executar\n-\n--------------------------------------\n-$ git tag v2.5 1b2e1d63ff\n--------------------------------------\n-\n-você pode se referir a 1b2e1d63ff pelo nome \"v2.5\". Se você pretende\n-compartilhar esse nome com outras pessoas (por exemplo, para identificar\n-uma versão de lançamento), você deveria criar um objeto \"tag\", e talvez\n-assiná-lo; veja linkgit:git-tag[1] para detalhes.\n-\n-Qualquer comando git que precise conhecer um commit pode receber\n-quaisquer desses nomes. Por exemplo:\n-\n--------------------------------------\n-$ git diff v2.5 HEAD\t # compara o HEAD atual com v2.5\n-$ git branch stable v2.5 # inicia um novo ramo chamado \"stable\" baseado\n-\t\t\t # em v2.5\n-$ git reset --hard HEAD^ # reseta seu ramo atual e seu diretório de\n-\t\t\t # trabalho a seu estado em HEAD^\n--------------------------------------\n-\n-Seja cuidadoso com o último comando: além de perder quaisquer mudanças\n-em seu diretório de trabalho, ele também remove todos os commits\n-posteriores desse ramo. Se esse ramo é o único ramo contendo esses\n-commits, eles serão perdidos. Também, não use 'git-reset' num ramo\n-publicamente visível de onde outros desenvolvedores puxam, já que vai\n-forçar unificações desnecessárias para que outros desenvolvedores limpem\n-a história. Se você precisa desfazer mudanças que você empurrou, use\n-'git-revert' no lugar.\n-\n-O comando 'git-grep' pode buscar strings em qualquer versão de seu\n-projeto, então\n-\n--------------------------------------\n-$ git grep \"hello\" v2.5\n--------------------------------------\n-\n-procura por todas as ocorrências de \"hello\" em v2.5.\n-\n-Se você deixar de fora o nome do commit, 'git-grep' irá procurar\n-quaisquer dos arquivos que ele gerencia no diretório corrente. Então\n-\n--------------------------------------\n-$ git grep \"hello\"\n--------------------------------------\n-\n-é uma forma rápida de buscar somente os arquivos que são rastreados pelo\n-git.\n-\n-Muitos comandos git também recebem um conjunto de commits, o que pode\n-ser especificado de várias formas. Aqui estão alguns exemplos com 'git-log':\n-\n--------------------------------------\n-$ git log v2.5..v2.6            # commits entre v2.5 e v2.6\n-$ git log v2.5..                # commits desde v2.5\n-$ git log --since=\"2 weeks ago\" # commits das últimas 2 semanas\n-$ git log v2.5.. Makefile       # commits desde v2.5 que modificam\n-\t\t\t\t# Makefile\n--------------------------------------\n-\n-Você também pode dar ao 'git-log' um \"intervalo\" de commits onde o\n-primeiro não é necessariamente um ancestral do segundo; por exemplo, se\n-as pontas dos ramos \"stable\" e \"master\" divergiram de um commit\n-comum algum tempo atrás, então\n-\n--------------------------------------\n-$ git log stable..master\n--------------------------------------\n-\n-irá listar os commits feitos no ramo \"master\" mas não no ramo\n-\"stable\", enquanto\n-\n--------------------------------------\n-$ git log master..stable\n--------------------------------------\n-\n-irá listar a lista de commits feitos no ramo \"stable\" mas não no ramo\n-\"master\".\n-\n-O comando 'git-log' tem uma fraqueza: ele precisa mostrar os commits em\n-uma lista. Quando a história tem linhas de desenvolvimento que\n-divergiram e então foram unificadas novamente, a ordem em que 'git-log'\n-apresenta essas mudanças é irrelevante.\n-\n-A maioria dos projetos com múltiplos contribuidores (como o kernel\n-Linux, ou o próprio git) tem unificações frequentes, e 'gitk' faz um\n-trabalho melhor de visualizar sua história. Por exemplo,\n-\n--------------------------------------\n-$ gitk --since=\"2 weeks ago\" drivers/\n--------------------------------------\n-\n-permite a você navegar em quaisquer commits desde as últimas duas semanas\n-de commits que modificaram arquivos sob o diretório \"drivers\". (Nota:\n-você pode ajustar as fontes do gitk segurando a tecla control enquanto\n-pressiona \"-\" ou \"+\".)\n-\n-Finalmente, a maioria dos comandos que recebem nomes de arquivo permitirão\n-também, opcionalmente, preceder qualquer nome de arquivo por um\n-commit, para especificar uma versão particular do arquivo:\n-\n--------------------------------------\n-$ git diff v2.5:Makefile HEAD:Makefile.in\n--------------------------------------\n-\n-Você pode usar 'git-show' para ver tal arquivo:\n-\n--------------------------------------\n-$ git show v2.5:Makefile\n--------------------------------------\n-\n-Próximos passos\n-----------\n-\n-Este tutorial deve ser o bastante para operar controle de revisão\n-distribuído básico para seus projetos. No entanto, para entender\n-plenamente a profundidade e o poder do git você precisa entender duas\n-idéias simples nas quais ele se baseia:\n-\n-  * A base de objetos é um sistema bem elegante usado para armazenar a\n-    história de seu projeto--arquivos, diretórios, e commits.\n-\n-  * O arquivo de índice é um cache do estado de uma árvore de diretório,\n-    usado para criar commits, restaurar diretórios de trabalho, e\n-    armazenar as várias árvores envolvidas em uma unificação.\n-\n-A parte dois deste tutorial explica a base de objetos, o arquivo de\n-índice, e algumas outras coisinhas que você vai precisar pra usar o\n-máximo do git. Você pode encontrá-la em linkgit:gittutorial-2[7].\n-\n-Se você não quiser continuar com o tutorial agora nesse momento, algumas\n-outras digressões que podem ser interessantes neste ponto são:\n-\n-  * linkgit:git-format-patch[1], linkgit:git-am[1]: Estes convertem\n-    séries de commits em patches para email, e vice-versa, úteis para\n-    projetos como o kernel Linux que dependem fortemente de patches\n-    enviados por email.\n-\n-  * linkgit:git-bisect[1]: Quando há uma regressão em seu projeto, uma\n-    forma de rastrear um bug é procurando pela história para encontrar o\n-    commit culpado. Git bisect pode ajudar a executar uma busca binária\n-    por esse commit. Ele é inteligente o bastante para executar uma\n-    busca próxima da ótima mesmo no caso de uma história complexa\n-    não-linear com muitos ramos unificados.\n-\n-  * link:everyday.html[GIT diariamente com 20 e tantos comandos]\n-\n-  * linkgit:gitcvs-migration[7]: Git para usuários de CVS.\n-\n-VEJA TAMBÉM\n---------\n-linkgit:gittutorial-2[7],\n-linkgit:gitcvs-migration[7],\n-linkgit:gitcore-tutorial[7],\n-linkgit:gitglossary[7],\n-linkgit:git-help[1],\n-link:everyday.html[git diariamente],\n-link:user-manual.html[O Manual do Usuário git]\n-\n-GIT\n----\n-Parte da suite linkgit:git[1].\n-- \n1.8.0.msysgit.0\n\n\n---\nThomas\n"}]}