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