From 98f22ed82e4e30c8477eebfa0f5073966248ba70 Mon Sep 17 00:00:00 2001 From: Ricardo Date: Mon, 6 Apr 2015 11:19:59 -0700 Subject: [PATCH] Update index-pt.html MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Small translation fixes and adding italic to english words used in portuguese text, like "commit" and "stage", where they are not a code reference. Pequenos ajustes na tradução e adição de itálico para palavras em inglês dentro do texto em português, quando não são comandos. --- index-pt.html | 160 +++++++++++++++++++++++++------------------------- 1 file changed, 80 insertions(+), 80 deletions(-) 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 @@ -

Uma Referência Visual de Git

+

Uma Referência Visual do Git

Outros Idiomas: @@ -35,7 +35,7 @@

Uma Referência Visual de Git

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 @@

Uso Básico

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).

@@ -92,25 +92,25 @@

Uso Básico

arquivos para selecionar interativamente partes de arquivos para copiar.

-

É 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.

@@ -122,20 +122,20 @@

Convenções

-

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.

Comandos em Detalhe

Diff

-

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 @@

Diff

Commit

-

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 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.)

@@ -177,25 +177,25 @@

Commit

Checkout

O comando checkout é usado para copiar arquivos da história (ou - stage) para o diretório de trabalho, e opcionalmente mudar de ramo.

+ stage) para o diretório de trabalho, e opcionalmente mudar de ramo.

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 @@

Checkout

poder executar 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 @@

Cometendo com um HEAD detachado

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 @@

Cometendo com um HEAD detachado

Reset

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.

+ 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.)

Merge

-

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.

Cherry Pick

-

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.

Rebase

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.

@@ -331,22 +331,22 @@

Rebase

Observações técnicas

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.