Ajustes ortograficos

book/01-introduction/sections/basics.asc

@@ -1,3 +1,4 @@
+[[r_git_basics]]
 === O Básico do Git
 
 Então, em poucas palavras, o que é o Git ?

book/02-git-basics/sections/aliases.asc

@@ -19,15 +19,15 @@ $ git config --global alias.st status
 
 Isto significa que, por exemplo, ao invés de digitar `git commit`, você só precisa digitar `git ci`. A medida que você for usando o Git, provavelmente usará outros comandos com frequência também. Então, não hesite em criar novos apelidos.
 
-Esta técnica também pode ser muito útil na criação de comandos que você acredita que deveriam existir. Por exemplo, para corrigir o problema de usabilidade que você encontrou em um arquivo _unstaging_, você pode adicionar seu próprio apelido unstage ao Git: 
+Esta técnica também pode ser muito útil na criação de comandos que você acredita que deveriam existir. Por exemplo, para corrigir o problema de usabilidade que você encontrou em um arquivo enquanto o removia do _staging_, você pode adicionar seu próprio apelido essa ação ao Git: 
 
 
 [source,console]
 ----
 $ git config --global alias.unstage 'reset HEAD --'
 ----
 
-Isto faz dos dois comandos a seguir equivalentes 
+Isto faz dos dois comandos a seguir equivalentes: 
 
 [source,console]
 ----

book/02-git-basics/sections/recording-changes.asc

@@ -84,8 +84,8 @@ Changes to be committed:
 ----
 
 É possível saber que o arquivo está preparado porque ele aparece sob o título ``Changes to be committed''.
-Se você fizer um _commit_ neste momento, a versão do arquivo que existia no instante em que você executou `git add`, é a que será armazenada no histórico de _snapshots_.
-Você deve se lembrar que, quando executou `git init` anteriormente, em seguida, você também executou `git add (arquivos)` - isso foi para começar a rastrear os arquivos em seu diretório.(((git commands, init)))(((git commands, add)))
+Se você fizer um _commit_ neste momento, a versão do arquivo que existia no instante em que você executou `git add` é a que será armazenada no histórico de _snapshots_.
+Você deve se lembrar que, quando executou `git init` anteriormente, em seguida você também executou `git add (arquivos)` - isso foi para começar a rastrear os arquivos em seu diretório.(((git commands, init)))(((git commands, add)))
 O comando `git add` recebe o caminho de um arquivo ou de um diretório. Se for um diretório, o comando adiciona todos os arquivos contidos nesse diretório recursivamente.
 
 ==== Preparando Arquivos Modificados

book/02-git-basics/sections/remotes.asc

@@ -97,7 +97,7 @@ Como você viu, para obter dados de seus projetos remotos, você pode executar:(
 $ git fetch [remote-name]
 ----
 
-O comando vai até aquele projeto remoto e extrai todos os dados daquele projeto que você ainda não tem. Depois que você faz isso, você deve ter como referência todos as ramificações(_branches_) daquele repositório remoto, que você pode mesclar(_merge_) com o atual ou inspecionar a qualquer momento.
+O comando vai até aquele projeto remoto e extrai todos os dados daquele projeto que você ainda não tem. Depois que você faz isso, você deve ter como referência todas as ramificações(_branches_) daquele repositório remoto, que você pode mesclar(_merge_) com o atual ou inspecionar a qualquer momento.
 
 Se você clonar um repositório, o comando automaticamente adiciona àquele repositório remoto com o nome `origin`. Então, `git fetch origin` busca qualquer novo trabalho que tenha sido enviado para aquele servidor desde que você o clonou ou fez a última busca(_fetch_). É importante notar que o comando `git fetch` só baixa os dados para o seu repositório local - ele não é automaticamente mesclado(_merge_) com nenhum trabalho seu ou modificação que você esteja trabalhando atualmente. Você deve mesclá-los manualmente dentro de seu trabalho quando você estiver pronto.
 
@@ -143,7 +143,7 @@ $ git remote show origin
 ----
 
 Ele lista a URL para o repositório remoto, bem como as informações de rastreamento do branch.
-O comando, de forma útil, comunica que se você estiver no branch master e executar `git pull`, ele irá mesclar (merge) automaticamente no branch master do servidor após buscar (fetch) todas as referências remotas.
+O comando, de forma útil, comunica que se você estiver no branch `master` e executar `git pull`, ele irá mesclar (merge) o branch remoto ao local automaticamente após buscar (fetch) todas as referências remotas.
 Ele também lista todas as referências remotas recebidas.
 
 Esse é um exemplo simples que você provavelmente encontrará.
@@ -179,7 +179,7 @@ Ele também mostra quais branches remotos do servidor você ainda não tem, quai
 ==== Removendo e Renomeando Remotes
 
 Você pode utilizar o `git remote rename` para alterar o nome curto de servidores remotos.(((git commands, remote)))
-Por exemplo, se você deseja renomear `pb` para` paul`, você pode fazer isso com `git remote rename`:
+Por exemplo, se você deseja renomear `pb` para `paul`, você pode fazer isso com `git remote rename`:
 
 [source,console]
 ----

book/02-git-basics/sections/tagging.asc

@@ -86,7 +86,7 @@ Date:   Mon Mar 17 21:52:11 2008 -0700
     changed the version number
 ----
 
-Este mostra as informações de tag, a data do commit atrelado a tag, e a mensagem antes mesmo de mostrar as informações do commit.
+Esse mostra as informações de tag, a data do commit atrelado a tag, e a mensagem antes mesmo de mostrar as informações do commit.
 
 ==== Tags de Tipo Leve
 
@@ -207,6 +207,7 @@ To [email protected]:schacon/simplegit.git
 ----
 
 Agora, quando alguém executar um clone ou pull a partir do seu repositório, ele vai puxar também todas as tags. 
+
 ==== Checando as Tags
 
 Você não pode realizar o checkout de uma tag no Git, uma vez que elas não podem ser movidas.

book/02-git-basics/sections/undoing.asc

@@ -6,7 +6,7 @@ Aqui, vamos rever algumas ferramentas básicas para desfazer modificações que
 Seja cuidadoso, porque nem sempre você pode voltar uma alteração desfeita.
 Essa é uma das poucas áreas do Git onde pode perder algum trabalho feito se você cometer algum engano.
 
-Um dos motivos mais comuns para desfazer um comando, aparece quando você executa um commit muito cedo e possivelmente esquecendo de adicionar alguns arquivos ou você escreveu a mensagem do commit de forma equivocada.
+Um dos motivos mais comuns para desfazer um comando aparece quando você executa um commit muito cedo e possivelmente esquece de adicionar alguns arquivos, ou você escreveu a mensagem do commit de forma equivocada.
 Se você quiser refazer este commit, execute o commit novamente usando a opção `--amend`:
 
 [source,console]
@@ -29,7 +29,7 @@ $ git add forgotten_file
 $ git commit --amend
 ----
 
-No final das contas você termina com um único commit – O segundo commit substitui o resultante do primeiro.
+No final das contas você termina com um único commit – o segundo commit substitui o resultante do primeiro.
 
 [[r_unstaging]]
 ==== Retirando um arquivo do Stage
@@ -75,7 +75,7 @@ Changes not staged for commit:
 ----
 
 O comando é um tanto quanto estranho, mas funciona.
-O arquivo `CONTRIBUTING.md` volta ao estado modificado porem está novamente fora do stage.
+O arquivo `CONTRIBUTING.md` volta ao estado modificado porém está novamente fora do stage.
 
 [NOTE]
 =====
@@ -126,7 +126,7 @@ Qualquer modificação que você fez no arquivo se foi -- O Git apenas substitui
 Nunca use este comando a não ser que você saiba com certeza que não quer salvar as modificações do arquivo.
 =====
 
-Se você gostaria de manter as modificações que fez no arquivo, porem precisa tirá-lo do caminho por enquanto, sugerimos que pule para a documentação sobre Branches<<ch03-git-branching#ch03-git-branching>>; esta geralmente é a melhor forma de fazer isso. 
+Se você gostaria de manter as modificações que fez no arquivo, porém precisa tirá-lo do caminho por enquanto, sugerimos que pule para a documentação sobre Branches<<ch03-git-branching#ch03-git-branching>>; esta geralmente é a melhor forma de fazer isso. 
 
 Lembre-se, qualquer coisa que sobre commit com Git pode quase sempre ser recuperada.
 Até mesmo commits que estava em algum branches que foram deletados ou commits que forma sobre escritos através de um `--amend` podem ser recuperados (veja<<ch10-git-internals#r_data_recovery>> para recuperação de dados).

book/02-git-basics/sections/viewing-history.asc

@@ -5,7 +5,7 @@ Depois de você ter criado vários commits ou se você clonou um repositório co
 A ferramenta mais básica e poderosa para fazer isso é o comando `git log`.
 
 Esses exemplos usam um projeto muito simples chamando ``simplegit''.
-Para conseguir o projeto, execute
+Para obter o projeto, execute
 
 [source,console]
 ----
@@ -90,8 +90,8 @@ index a0a60ae..47c6340 100644
 \ No newline at end of file
 ----
 
-Essa opção mostrar a mesma informação mas com um diff diretamente após cada item. 
-Isso é de muita ajuda para revisão de código ou para rapidamente procurar o que aconteceu durante uma série de commits que uma colaborador tenha adicionado.
+Essa opção mostra a mesma informação mas com um diff diretamente após cada item. 
+Isso é de muita ajuda para revisão de código ou para rapidamente procurar o que aconteceu durante uma série de commits que um colaborador tenha adicionado.
 Você pode também usar uma série de opções resumidas com o `git log`.
 Por exemplo, se você quer ver algumas estatísticas abreviadas para cada commit, você pode usar a opção `--stat`:
 
@@ -129,13 +129,13 @@ Date:   Sat Mar 15 10:31:28 2008 -0700
 ----
 
 Como você pode ver, a opção `--stat` apresenta abaixo de cada commit uma lista dos arquivos modificados, quantos arquivos foram modificados, e quantas linhas nestes arquivos foram adicionadas e removidas.
-Por último ela também colocar um resumo das informações.
+Por último ela também coloca um resumo das informações.
 
 Uma outra opção realmente muito util é `--pretty`.
 Essa opção modifica os registros retornados para formar outro formato diferente do padrão. 
 Algumas opções pré-definidas estão disponíveis para você usar.   
 A opção `oneline` mostra cada commit em uma única linha, esta é de muita ajuda se você está olhando para muitos commits.
-Em adição, as opções `short`, `full`, e `fuller` apresentam o retorno quase no mesmo formato porem com menos ou mais informações, respectivamente:
+Em adição, as opções `short`, `full`, e `fuller` apresentam o retorno quase no mesmo formato porém com menos ou mais informações, respectivamente:
 
 [source,console]
 ----
@@ -146,7 +146,7 @@ a11bef06a3f659402fe7563abf99ad00de2209e6 first commit
 ----
 
 A opção mais interessante é `format`, a qual permite a você especificar seu próprio formato de registros de retorno.
-Isso é especialmente útil quando você esta gerando um retorno para uma máquina analisar – pois você especifica o formato explicitamente, você sabe que isso não irá mudar com as atualizações do Git:(((log formatting)))
+Isso é especialmente útil quando você esta gerando um retorno para uma máquina analisar – como você especifica o formato explicitamente, você sabe que isso não irá mudar com as atualizações do Git:(((log formatting)))
 
 [source,console]
 ----
@@ -203,7 +203,7 @@ $ git log --pretty=format:"%h %s" --graph
 *  11d191e Merge branch 'defunkt' into local
 ----
 
-Esse tipo de retorno se tornará mais interessante conforme formos criando branches e merges no próximo capitulo.
+Esse tipo de retorno se tornará mais interessante conforme formos criando branches e merges no próximo capítulo.
 
 Essas são apenas algumas opções simples de formatações de retorno para `git log` – existem muitas mais.
 <<rlog_options>> lista as opções que nós já abordamos, assim como algumas outras opções de formatação mais comuns que talvez sejam muito úteis, juntamente com o como ela mudam o retorno do comando log.
@@ -226,12 +226,12 @@ Essas são apenas algumas opções simples de formatações de retorno para `git
 
 ==== Limitando o retorno do comando Log
 
-Em adição ás opções de formatação do retorno, `git log` leva um número útil de opções de limitação – que são, opções que lhe permitem mostrar apenas um subconjunto de commits.
+Em adição às opções de formatação do retorno, `git log` leva um número útil de opções de limitação – ou seja, opções que lhe permitem mostrar apenas um subconjunto de commits.
 Você já viu essa opção antes – a opção `-2`, a qual mostra apenas os dois últimos commits.
-De fato, você pode usar `-<n>`, onde `n` é qualquer número inteiro para mostra os ultimos `n` commits.
+De fato, você pode usar `-<n>`, onde `n` é qualquer número inteiro para mostrar os ultimos `n` commits.
 Na verdade, você não gostará de usar isso frequentemente, pois o Git por padrão enquadra todo o retorno através de uma página então você vê apenas uma página de registros por vez.  
 
-Entretanto, as opções de lina do tempo tais como `--since` e `--until` são muito uteis.
+Entretanto, as opções de linha do tempo tais como `--since` e `--until` são muito uteis.
 Por exemplo, esse comando retorna a lista de commits feitos nas últimas duas semanas:
 
 [source,console]

book/03-git-branching/sections/nutshell.asc

@@ -3,13 +3,13 @@
 
 Para realmente entender como o Git trabalha com Branches, precisamos dar um passo atrás e examinar como o Git armazena seus dados.
 
-Como você deve se lembrar de << ch01-introdução # ch01-introdução >>, o Git não armazena dados como uma série de mudanças ou diferenças, mas sim como uma série de snapshots (instantâneos de um momento) .
+Como você deve se lembrar de <<ch01-r_git_basics#ch01-r_git_basics>>, o Git não armazena dados como uma série de mudanças ou diferenças, mas sim como uma série de snapshots (instantâneos de um momento) .
 
 Quando você faz um commit, o Git armazena um objeto de commit que contém um ponteiro para o snapshot do conteúdo que você testou.
 Este objeto também contém o nome do autor e o e-mail, a mensagem que você digitou e ponteiros para o commit ou commits que vieram antes desse commit (seu pai ou pais): sem pai para o commit inicial, um pai para um commit normal, e vários pais para um commit que resulta de uma fusão de dois ou mais branches.
 
 Para verificar isso, vamos assumir que você tem um diretório contendo três arquivos, e você seleciona todos eles e efetua o commit.
-Ele Prepara os arquivos e calcula uma verificação para cada um (o hash SHA-1 que mencionamos em << ch01-introdução # ch01-introdução >>), armazena essa versão do arquivo no repositório Git (Git se refere a eles como blobs), e adiciona esse hash de verificação à área de preparação (staging area):
+Ele Prepara os arquivos e calcula uma verificação para cada um (o hash SHA-1 que mencionamos em <<ch01-r_git_basics#ch01-r_git_basics>>), armazena essa versão do arquivo no repositório Git (Git se refere a eles como blobs), e adiciona esse hash de verificação à área de preparação (staging area):
 
 [source,console]
 ----