diff --git a/index-pt.html b/index-pt.html index 454be6d..bf2ea6b 100644 --- a/index-pt.html +++ b/index-pt.html @@ -7,7 +7,7 @@
-Esta página fornece uma breve referência visual para os comandos mais comuns do git. Uma vez que você saiba um pouco sobre como o git - funciona, esta página pode solidificar o seu entendimento. Se você está + funciona, esta página pode consolidar o seu entendimento. Se você está interessado em saber como está página foi criada, veja o meu repositório no GitHub.
@@ -64,25 +64,25 @@Os quatro comandos acima copiam arquivos entre o diretório de - trabalho, o stage (também chamado de índice), e a história (na forma de - commits).
+ trabalho, o stage (também chamado de índice), e a história (na forma de + commits).git add arquivos
copia arquivos (em
- seus estados atuais) para o stage.git commit
salva uma cópia do stage como um
- commit.git commit
salva uma cópia do stage como um
+ commit.git reset -- arquivos
remove arquivos do
- stage; isto é, copia arquivos do último commit para o stage.
+ stage; isto é, copia arquivos do último commit para o stage.
Use esse comando para "desfazer" um git add
arquivos
. Você também pode executar git
- reset
para remover todos os arquivos do stage.git checkout -- arquivos
copia
- arquivos do stage para o diretório de trabalho. Use isso
+ arquivos do stage para o diretório de trabalho. Use isso
para descartar alterações locais.É também possível passar por cima do stage e copiar (check out) - arquivos diretamente da história ou de commits sem copiar o aquivo para - o stage.
+É também possível passar por cima do stage e copiar (check out) + arquivos diretamente da história ou de commits sem copiar o aquivo para + o stage.
git commit -a
é equivalente a executar git
- add em todos os arquivos que existiam no último commit, e
+ add em todos os arquivos que existiam no último commit, e
então executar git commit.git commit arquivos
cria um novo commit com
- o conteúdo do último commit, mais uma cópia de arquivos no
+ git commit arquivos
cria um novo commit com
+ o conteúdo do último commit, mais uma cópia de arquivos no
diretório de trabalho. Além disso, os arquivos são copiados
- para o stage.git checkout HEAD -- arquivos
copia os
- arquivos do último commit para ambos o stage e o diretório de
+ arquivos do último commit para ambos o stage e o diretório de
trabalho.Commits são mostrados em verde com uma identidade de 5 caracteres, e +
commits são mostrados em verde com uma identidade de 5 caracteres, e eles apontam para os seus pais (parents). Os ramos (branches) são - mostrados em laranja, e eles apontam para commits específicos. O ramo + mostrados em laranja, e eles apontam para commits específicos. O ramo atual é identificado pela referência especial HEAD, que está - atachada àquele ramo. Nessa imagem, os últimos cinco commits são + atachada àquele ramo. Nessa imagem, os últimos cinco commits são mostrados, sendo ed489 o mais recente. master (o ramo - atual) aponta para esse commit, enquanto maint (outro ramo) - aponta para um ancestral do commit do master. + atual) aponta para esse commit, enquanto maint (outro ramo) + aponta para um ancestral do commit do master.
Existem várias formas de ver as diferenças entre commits. Abaixo +
Existem várias formas de ver as diferenças entre commits. Abaixo estão alguns exemplos comuns. Qualquer desses comandos pode opcionalmente receber nomes de arquivos como argumentos que restringem as diferenças a esses arquivos.
@@ -144,18 +144,18 @@Quando você comete, o git cria um novo commit usando os arquivos do - stage e define os pais como o commit atual. Então ele aponta o ramo - atual para esse novo commit. Na figura abaixo, o ramo atual é o +
Quando você comete, o git cria um novo commit usando os arquivos do + stage e define os pais como o commit atual. Então ele aponta o ramo + atual para esse novo commit. Na figura abaixo, o ramo atual é o master. Antes do comando ser executado, master - apontava para ed489. Após, um novo commit, f0cec, foi + apontava para ed489. Após, um novo commit, f0cec, foi criado, com ancestral ed489, e então master foi movido - para o novo commit.
+ para o novo commit.Esse mesmo processo ocorre também quando o ramo atual é um
- ancestral de outro ramo. Abaixo, um commit ocorre no ramo
+ ancestral de outro ramo. Abaixo, um commit ocorre no ramo
maint, o qual era um ancestral de master, resultando
em 1800b. Após, maint não é mais um ancestral de
master. Para juntar as duas histórias, um Commit
- As vezes um engano ocorre em um commit, mas isso é fácil de corrigir
+ As vezes um engano ocorre em um commit, mas isso é fácil de corrigir
com O comando checkout é usado para copiar arquivos da história (ou
- stage) para o diretório de trabalho, e opcionalmente mudar de ramo.git commit --amend
. Quando você usa esse comando, o git
- cria um novo commit com os mesmos pais do commit atual. (O commit antigo
+ cria um novo commit com os mesmos pais do commit atual. (O commit antigo
será descartado se nada fizer referência a ele.)Commit
Checkout
Quando um nome de arquivo (e/ou -p
) é fornecido, o git
- copia esse arquivo do commit para o stage e o diretório de trabalho.
+ copia esse arquivo do commit para o stage e o diretório de trabalho.
Por exemplo, git checkout HEAD~ foo.c
copia o arquivo
- foo.c
do commit chamado HEAD~ (os pais do commit
- atual) para o diretório de trabalho, e também para o stage. (Se nenhum
- commit é fornecido, os arquivos são copiados do stage.) Note que não há
+ foo.c
do commit chamado HEAD~ (os pais do commit
+ atual) para o diretório de trabalho, e também para o stage. (Se nenhum
+ commit é fornecido, os arquivos são copiados do stage.) Note que não há
mudança no ramo.
Quando um nome de arquivo não é fornecido mas a referência é um ramo (local), HEAD é movido para aquele ramo (isto é, nós - passamos para aquele ramo), e então o stage e o diretório de trabalho - são modificados para coincidir com o conteúdo daquele commit. Qualquer - arquivo que existe no novo commit (a47c3 abaixo) é copiado; - qualquer arquivo que existe no antigo commit (ed489) mas não no - novo commit é excluído; e qualquer arquivo que não existe em ambos é + passamos para aquele ramo), e então o stage e o diretório de trabalho + são modificados para coincidir com o conteúdo daquele commit. Qualquer + arquivo que existe no novo commit (a47c3 abaixo) é copiado; + qualquer arquivo que existe no antigo commit (ed489) mas não no + novo commit é excluído; e qualquer arquivo que não existe em ambos é ignorado.
@@ -209,7 +209,7 @@git checkout v1.6.6.1
(que é uma etiqueta,
não um ramo), compilar, instalar, e então passar de volta para outro
ramo, por exemplo executado git checkout master
. Todavia,
- efetuar um commit funciona um pouco diferente em um HEAD detachado; isso
+ efetuar um commit funciona um pouco diferente em um HEAD detachado; isso
é discutido abaixo.
@@ -223,7 +223,7 @@ Uma vez que você faz um checkout de algo, por exemplo - master, o commit (presumivelmente) não recebe outra referência, + master, o commit (presumivelmente) não recebe outra referência, e acaba excluído. Note que após o comando, não há nada fazendo referência para 2eecb.
@@ -238,92 +238,92 @@O comando reset move o ramo atual para uma nova posição, e - opcionalmente atualiza o stage e o diretório de trabalho. Ele também é - usado para copiar arquivos da história para o stage sem alterar o + opcionalmente atualiza o stage e o diretório de trabalho. Ele também é + usado para copiar arquivos da história para o stage sem alterar o diretório de trabalho.
-Se um commit é executado sem um nome de arquivo, o ramo atual é
- movido para aquele commit, e então o stage é atualizado para coincidir
- com esse commit. Se --hard
é fornecido, o diretório de
+
Se um commit é executado sem um nome de arquivo, o ramo atual é
+ movido para aquele commit, e então o stage é atualizado para coincidir
+ com esse commit. Se --hard
é fornecido, o diretório de
trabalho também é atualizado. Se --soft
é fornecido,
nenhum é atualizado.
Se um commit não é fornecido, será usado o HEAD. Nesse - caso, o ramo não é alterado, mas o stage (e opcionalmente o diretório de +
Se um commit não é fornecido, será usado o HEAD. Nesse
+ caso, o ramo não é alterado, mas o stage (e opcionalmente o diretório de
trabalho, se --hard
é fornecido) são atualizados com o
- conteúdo do último commit.
Se um nome de arquivo (e/ou -p
) é fornecido, então o
comando funciona similarmente ao comando checkout com um nome de arquivo, exceto que
- apenas o stage (e não o diretório de trabalho) é atualizado. (Você pode
- também especificar o commit a partir do qual copiar os arquivos, em vez
+ apenas o stage (e não o diretório de trabalho) é atualizado. (Você pode
+ também especificar o commit a partir do qual copiar os arquivos, em vez
de HEAD.)
Um merge cria um novo commit que incorpora mudanças de outros - commits. Antes de executar um merge, o stage deve estar igual ao último - commit. O caso trivial é quando o outro commit é um ancestral do commit +
Um merge cria um novo commit que incorpora mudanças de outros + commits. Antes de executar um merge, o stage deve estar igual ao último + commit. O caso trivial é quando o outro commit é um ancestral do commit atual; em tal caso nada ocorre. O próximo caso mais simples é quando o - commit atual é um ancestral do outro commit. Isso resulta em um merge + commit atual é um ancestral do outro commit. Isso resulta em um merge fast-forward. A referência é simplesmente movida, e então é - efetuado um checkout do novo commit.
+ efetuado um checkout do novo commit.Caso contrário, um merge "real" deve ocorrer. Você pode selecionar outras estratégias, mas o padrão é efetuar um merge "recursivo", o qual - basicamente considera o commit atual (ed489 abaixo), o outro - commit (33104), e o ancestral comum a ambos (b325c), e + basicamente considera o commit atual (ed489 abaixo), o outro + commit (33104), e o ancestral comum a ambos (b325c), e efetua um merge three-way. O resultado é salvo no diretório de trabalho e no - stage, e então um commit é executado, com um ancestral adicional - (33104) para o novo commit.
+ stage, e então um commit é executado, com um ancestral adicional + (33104) para o novo commit.O comando cherry-pick "copia" um commit, criando um novo commit no ramo - atual com a mesma mensagem e modificações de outro commit.
+O comando cherry-pick "copia" um commit, criando um novo commit no ramo + atual com a mesma mensagem e modificações de outro commit.
Um rebase é uma alternativa a um merge para - combinar vários ramos. Enquanto um merge cria um único commit com dois - pais, gerando uma história não-linear, um rebase efetua os commits do + combinar vários ramos. Enquanto um merge cria um único commit com dois + pais, gerando uma história não-linear, um rebase efetua os commits do ramo atual em outro ramo, gerando uma história linear. Em essência, isso é uma forma automática de executar vários cherry-picks em sequência.
-O comando acima considera todos os commits que existem em +
O comando acima considera todos os commits que existem em topic mas não em master (a saber 169a6 e - 2c33a), executa esses commits em master, e então move - o HEAD para o novo commit. Note que os commits antigos serão descartados + 2c33a), executa esses commits em master, e então move + o HEAD para o novo commit. Note que os commits antigos serão descartados se nada mais fizer referência a eles.
Para limitar quanto se quer ir para trás, use a opção
--onto
. O seguinte comando executa em master os
- commits mais recentes do ramo atual desde 169a6
+ commits mais recentes do ramo atual desde 169a6
(exclusivamente), a saber 2c33a.
Existe também o comando git rebase --interactive
, o qual
permite fazer coisas mais complicadas do que simplesmente executar
- novamente commits, a saber, remover, reordenar, modificar, e "amassar"
- commits (squashing). Não existe uma figura clara para representar isso;
+ novamente commits, a saber, remover, reordenar, modificar, e "amassar"
+ commits (squashing). Não existe uma figura clara para representar isso;
veja git-rebase(1)
para mais detalhes.
O conteúdo dos arquivos não é na verdade armazenado no index - (.git/index) ou em objetos commit. Em vez disso, cada arquivo + (.git/index) ou em objetos commit. Em vez disso, cada arquivo é armazenado no objeto base-de-dados (.git/objects) como um blob, identificado pelo seu código hash SHA-1. O arquivo index lista os nomes de arquivos juntamente com o identificador do blob - associado, bem como alguns outros dados. Para commits, existe um tipo de + associado, bem como alguns outros dados. Para commits, existe um tipo de dado adicional, uma árvore, também identificado pelo seu código hash. Árvores correspondem aos diretórios no diretório de trabalho, e contém uma lista das árvores e blobs correspondentes a cada nome de - arquivo naquele diretório. Cada commit armazena o identificador da sua + arquivo naquele diretório. Cada commit armazena o identificador da sua árvore, que por sua vez contém todos os blobs e outras árvores - associadas àquele commit.
+ associadas àquele commit. -Se você realiza um commit usando um HEAD detachado, o último commit é +
Se você realiza um commit usando um HEAD detachado, o último commit é
na verdade referenciado por algo: o reflog para o HEAD. Todavia, esse
- possui data de validade, logo em algum momento posterior o commit
- será finalmente excluído, de forma similar aos commits excluídos com
+ possui data de validade, logo em algum momento posterior o commit
+ será finalmente excluído, de forma similar aos commits excluídos com
git commit --amend
ou git rebase
.