WIP: fix typos

Author: gustadsg

book/08-customizing-git/sections/config.asc

@@ -14,9 +14,9 @@ $ git config --global user.email fulanodetal@exemplo.br
 
 Agora você aprenderá algumas das opções mais interessantes que podem ser configuradas para personalizar seu uso do Git.
 
-Antes, uma revisão rápida: o git usa uma série de arquivos de configuração para determinar comportamentos não padrão desejados.
+Antes, uma revisão rápida: o Git usa uma série de arquivos de configuração para determinar comportamentos não padrão desejados.
 O primeiro lugar em que o Git procura por esses valores é o arquivo `/etc/gitconfig`, que contém definições para todos os usuários do sistema e todos os seus repositórios.
-Se você passar a opção `--system` para o `git config`, ele vai ler e escrever especificamente neste arquivo.
+Se você passar a opção `--system` para o `git config`, o Git vai ler e escrever especificamente neste arquivo.
 
 
 O próximo lugar que o Git olha é o arquivo `~/.gitconfig` (ou `~/.config/git/config`), que é específico para cada usuário.
@@ -69,7 +69,7 @@ Por exemplo, suponha que você tenha criado um arquivo de template em `~/.gitmes
 
 [source,text]
 ----
-linha com assunto
+linha de assunto
 
 o que aconteceu
 
@@ -84,7 +84,7 @@ $ git config --global commit.template ~/.gitmessage.txt
 $ git commit
 ----
 
-Assim, o seu editor iniciará com algo algo parecido com esse modelo de mensagem quando você fizer commit: 
+Assim, o seu editor iniciará com algo parecido com esse modelo de mensagem quando você fizer commit: 
 
 [source,text]
 ----
@@ -124,7 +124,7 @@ Se você executar isso, Git irá imprimir a saída completa de todos os comandos
 ===== `user.signingkey`
 
 (((GPG)))
-Se você estiver criando tags anotadas assinadas (como discutido em <<ch07-git-tools#r_signing>>), deginir sua chave de assinatura GPG nas configurações torna as coisas mais fáceis.
+Se você estiver criando tags anotadas assinadas (como discutido em <<ch07-git-tools#r_signing>>), definir sua chave de assinatura GPG nas configurações torna as coisas mais fáceis.
 Defina a sua chave desta forma:
 
 [source,console]
@@ -142,7 +142,7 @@ $ git tag -s <tag-name>
 ===== `core.excludesfile`
 
 (((excludes)))(((.gitignore)))
-Você pode colocar padrões no arquivo `.gitignore` do seu prjeto para que o git não os veja como arquivos não rastreados nem tente adicioná-los quando você executar `git add`, como discutido em <<ch02-git-basics#r_ignoring>>.
+Você pode colocar padrões no arquivo `.gitignore` do seu projeto para que o git não os veja como arquivos não rastreados nem tente adicioná-los quando você executar `git add`, como discutido em <<ch02-git-basics#r_ignoring>>.
 
 Porém, algumas vezes você deseja ignorar alguns arquivos em todos os repositórios em que você trabalha.
 Se seu computador estiver rodando Mac OS X, você provavelmente está familiarizado com os arquivos `.DS_Store`.
@@ -186,7 +186,7 @@ in 0.1 seconds automatically...
 ----
 
 Observe o ``0.1 seconds''. `help.autocorrect` na verdade é um inteiro que representa décimos de segundo.
-Então, se você definí-lo como 50, o Git te dará 5 segundos para mudar de ideia antes de executar o comando automaticamente corrigido.
+Então, se você defini-lo como 50, o Git te dará 5 segundos para mudar de ideia antes de executar o comando automaticamente corrigido.
 
 ==== Cores no Git
 
@@ -206,7 +206,7 @@ $ git config --global color.ui false
 
 A configuração padrão é `auto`, o que colore a saída quando ela está indo direto para o terminal, mas omite o controle de cor quando a saída é redirecionada para um pipe ou arquivo.
 
-Você também pode definí-lo para `always` para ignorar a difereça entre terminais e pipes.
+Você também pode defini-lo para `always` para ignorar a difereça entre terminais e pipes.
 Você raramente vai quer fazer isso; na maioria dos casos, se você quiser manter as cores na saída redirecionada, poderá passar a opção `--color` para o comando Git para foçar o uso de cores.
 A configuração padrão é quase sempre o que você quer usar.
 
@@ -239,11 +239,11 @@ Apesar de o Git possuir uma implementação interna de diff, que viemos mostrand
 Você também pode definir uma ferramenta gráfica de resolução de conflitos ao invés de resolvê-los manualmente.
 Nós demonstraremos como configurar o Performance Visual Merge (P4Merge) para fazer seus diffs e resoluções de conflitos, porque é uma interface e boa e gratuita.
 
-Se quiser testar, P4Merge funciona na maior parte das platafomas, então você provavelmte conseguirá usar.
+Se quiser testar, P4Merge funciona na maior parte das plataformas, então você provavelmente conseguirá usar.
 Nos exemplos, usaremos caminhos que funcionam em Mac e Linux; se você usa Windows, deverá trocar `/usr/local/bin` pelo caminho do executável no seu ambiente.
 
 Para começar, https://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools[baixe P4Merge no Perforce].
-Depois, você deverá configurar um wrapper scripts externos para executar seus comandos.
+Depois, você deverá configurar wrapper scripts externos para executar seus comandos.
 Usaremos o caminho do Mac para o executável; em outras plataformas, será onde o seu `p4merge` estiver instalado.
 Configure um wrapper script de merge chamado `extMerge` para chamar seu binário com todos os argumentos disponíveis:
 
@@ -363,7 +363,7 @@ Some of the tools listed above only work in a windowed
 environment. If run in a terminal-only session, they will fail.
 ----
 
-Se você não tem interesse em usar a ferramanta KDiff3 para diff, mas prefere utilizá-la em resolução de merge e o comando kdiff3 está definido no seu path, você pode executar
+Se você não tem interesse em usar a ferramenta KDiff3 para diff, mas prefere utilizá-la em resolução de merge e o comando kdiff3 está definido no seu path, você pode executar
 
 [source,console]
 ----
@@ -383,10 +383,10 @@ O Git tem algumas opções para ajudar com esses problemas.
 
 (((crlf)))(((line endings)))
 Se estiver programando em Windows e trabalhando com pessoas que não estão (ou vice-versa), você provavelmente vai ter problema com fins de linha em algum momento.
-Isso aocntece porque o Windows usa tanto amobos caracteres de carriage-return character e linefeed (CR e LF) para novas linhas nos seus arquivos, ao mesmo tempo que Mac e Linux usam apenas LF.
-Essa é uma diferença sutil e que incomda bastante em trabalho cross-platform; muitos editores de texto no Windows silenciosamente substituem fins de linha LF existentes por CRLF, ou inserem ambos os caracteres de fim de linha quando a tecla enter é pressionada.
+Isso aocntece porque o Windows usa tanto ambos caracteres de carriage-return character e linefeed (CR e LF) para novas linhas nos seus arquivos, ao mesmo tempo que Mac e Linux usam apenas LF.
+Essa é uma diferença sutil e que incomoda bastante em trabalho cross-platform; muitos editores de texto no Windows silenciosamente substituem fins de linha LF existentes por CRLF, ou inserem ambos os caracteres de fim de linha quando a tecla enter é pressionada.
 
-O git lida com isso convertendo automaticamente todos os fins de linha CRLF por LF quando um arquivo é adicionado ao index e faz o inverso quando leva código para o seu sistema de arquivos.
+O Git lida com isso convertendo automaticamente todos os fins de linha CRLF para LF quando um arquivo é adicionado ao index e faz o processo inverso quando leva código para o seu sistema de arquivos.
 Você pode ativar essa funcionalidade por meio da configuração `core.autocrlf`.
 Se você estiver usando Windows, defina-a como `true` - isso converte os fins de linha de LF para CRLF quando trouxer código para sua máquina:
 
@@ -395,8 +395,8 @@ Se você estiver usando Windows, defina-a como `true` - isso converte os fins de
 $ git config --global core.autocrlf true
 ----
 
-Se estiver usando Linux ou Mac que use fim de linha LF, você não vai querer que o Git faça essa conversão automática; no entanto, se um arquivo com CRFL acidentalmente for introduzido, você pode querer que o Git o corrija.
-Você pode dizer ao git para converter CRFL em LF ao fazer commit, mas não o caminho inverso definindo `core.autocrlf` como `input`:
+Se estiver usando Linux ou Mac que use fim de linha LF, você não vai querer que o Git faça essa conversão automática; no entanto, se um arquivo com CRLF acidentalmente for introduzido, você pode querer que o Git o corrija.
+Você pode dizer ao Git para converter CRFL em LF ao fazer commit, mas não o caminho inverso definindo `core.autocrlf` como `input`:
 
 [source,console]
 ----
@@ -417,9 +417,9 @@ $ git config --global core.autocrlf false
 O Git vem pré configurado para detectar e resolver alguns problemas de espaço em branco.
 Ele procura por seis tipos primários de problemas - três são habilitados por padrão e os outros três desligados, mas podem ser habilitados.
 
-Os três que são habilitados por padrão são `blank-at-eol`, que busca espaço em branco no fim da linha; `blank-at-eof`, que busca linhas em branch no fim do arquivo; e `space-before-tab`, que busca por espaço em branco antes dos tabs no início da linha.
+Os três que são habilitados por padrão são `blank-at-eol`, que busca espaço em branco no fim da linha; `blank-at-eof`, que busca linhas em branco no fim do arquivo; e `space-before-tab`, que busca por espaço em branco antes dos tabs no início da linha.
 
-Os três que vem desabilitados por padrão, mas podem ser habilitados são  `indent-with-non-tab`, que busca linhas que começam com espaços em branco ao invés de tabs (e é controlado pela opção `tabwidth`); `tab-in-indent`, que procura por tabs na porção de identação da linha; e `cr-at-eol`, que diz ao Git que caracteres CR no fim das linhas são OK.
+Os três que vem desabilitados por padrão, mas podem ser habilitados são  `indent-with-non-tab`, que busca linhas que começam com espaços em branco ao invés de tabs (e é controlado pela opção `tabwidth`); `tab-in-indent`, que procura por tabs na porção de indentação da linha; e `cr-at-eol`, que informa ao Git que é aceitável caracteres CR no fim das.
 
 Você pode dizer ao Git quais dessas quer habilitar definindo `core.whitespace` com os valores que você quer ligados ou desligados, separados por vírgulas.
 Você pode desabilitar uma opção acrescentando um `-` na frente do nome, ou usar o valor default deixando o nome fora da string de configuração.
@@ -440,7 +440,7 @@ $ git config --global core.whitespace \
 ----
 
 O Git vai detectar esses problemas quando você executar o comando `git diff` e tentar colori-los para que você possa resolvê-los antes de fazer commit.
-Ele também usará essas configurações para te ajudar a aplicarpatches com `git apply`.
+Ele também usará essas configurações para te ajudar a aplicar patches com `git apply`.
 Quando você estiver aplicando patches, você pode pedir ao Git para te avisar se terá os problemas de espaço em branco especificados.
 
 [source,console]
@@ -466,7 +466,7 @@ Muito menos opções de configuração estão disponíveis para o lado do servid
 
 O Git é capaz de garantir que cada objeto recebido durante um push ainda corresponde com sua soma SHA-1 e aponta para objetos válidos.
 No entanto, isso não é feito por padrão; é uma operação relativamente cara, e por isso pode retardar a operação, especialmente em grandes repositórios ou pushes.
-Se você quiser que o git cheque a consistência dos objetos em todos os pushes, você pode foçar isso definindo a configuração `receive.fsckObjects` como `true`:
+Se você quiser que o Git cheque a consistência dos objetos em todos os pushes, você pode forçar isso definindo a configuração `receive.fsckObjects` como `true`:
 
 [source,console]
 ----
@@ -488,7 +488,7 @@ $ git config --system receive.denyNonFastForwards true
 ----
 
 A outra forma de fazer isso é por meio de receive hooks no servidor, veremos isto num instante.
-Essa abordagem permite que você faça coisas mais cmoplexas como negar non-fast-forwards para um certo subconjunto de usuários.
+Essa abordagem permite que você faça coisas mais complexas como negar non-fast-forwards para um certo subconjunto de usuários.
 
 ===== `receive.denyDeletes`