Browse Source
Remove a translation of a document that was left stale. * ta/remove-stale-translated-tut: Remove Documentation/pt_BR/gittutorial.txtmaint
Junio C Hamano
12 years ago
1 changed files with 0 additions and 675 deletions
@ -1,675 +0,0 @@
@@ -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]. |
||||
Loading…
Reference in new issue