Merge branch 'ta/remove-stale-translated-tut' into maint
* ta/remove-stale-translated-tut: Remove Documentation/pt_BR/gittutorial.txt
This commit is contained in:
Junio C Hamano
@ -1,675 +0,0 @@
|
|||||||
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].
|
|
||||||
Reference in New Issue
Block a user