From 51db24a411ac3054d363e9da3357b322f38c9095 Mon Sep 17 00:00:00 2001
From: Eduardo Junior <edujrrib@gmail.com>
Date: Thu, 17 Dec 2015 00:47:33 -0200
Subject: [PATCH] =?UTF-8?q?Corrige=20ortogr=C3=A1fica=20em=20todos=20os=20?=
 =?UTF-8?q?cap=C3=ADtulos=20conclu=C3=ADdos?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 cap02.Rmd          |   4 +-
 cap03.Rmd          |  44 +++++++-------
 cap04.Rmd          |  16 ++---
 cap05.Rmd          | 142 ++++++++++++++++++++++-----------------------
 cap06.Rmd          |  24 ++++----
 cap07.Rmd          |  16 ++---
 cap08/cap08_cs.Rmd |   6 +-
 cap08/cap08_dt.Rmd |  18 +++---
 8 files changed, 135 insertions(+), 135 deletions(-)

diff --git a/cap02.Rmd b/cap02.Rmd
index 8d11890..318d7bf 100644
--- a/cap02.Rmd
+++ b/cap02.Rmd
@@ -290,7 +290,7 @@ ou editando diretamente no arquivo `/.gitconfig`.
 **Pelo terminal:**
 
 Execute o comando abaixo com o atalho de sua preferência e o nome
-completo do camando o qual deseja criar o alias.
+completo do comando o qual deseja criar o alias.
 
 ```{r, engine="bash", eval=FALSE}
 git config --global alias.nome_do_alias "comando inteiro"
@@ -389,5 +389,5 @@ A partir disso, todos os arquivos que estão na lista serão ignorados
 pelo usuário.
 
 Finalmente com a instalação, configuração essencial (usuário e e-mail) e
-configurações adicionais concluídos, podemos começar a utilizar o Git
+configurações adicionais concluídas, podemos começar a utilizar o Git
 para versionar nossos projetos.
diff --git a/cap03.Rmd b/cap03.Rmd
index ebcc3b2..c725951 100644
--- a/cap03.Rmd
+++ b/cap03.Rmd
@@ -99,7 +99,7 @@ cd meu1repo
 git init
 ```
 
-O Git retorna a mensagem de inicilização do repositório. Nesse momento
+O Git retorna a mensagem de inicialização do repositório. Nesse momento
 ele cria um diretório oculto `.git/` com subdiretórios que são o coração
 do sistema de versionamento. Você não deve modificar nada nesse
 diretório. É por essa razão que ele é oculto. Alterar o conteúdo pode
@@ -200,7 +200,7 @@ semanas e até anos atrás.
 O controle de versão não é apenas voltar os arquivos para o conteúdo que
 eles tinham no passado. Arquivos rastreados que foram deletados ou
 renomeados são recuperados. Até mesmo as permissões de
-leitura/escrita/execussão dos arquivos são comtempladas no
+leitura/escrita/execução dos arquivos são contempladas no
 versionamento.
 
 ```{r, engine="bash", echo=-c(1:2)}
@@ -215,7 +215,7 @@ O arquivo `README.txt` já é visto pelo Git como um arquivo com o qual
 ele deve se "preocupar", pois está sob versionamento. Vamos agora fazer
 um registro definitivo sobre o estado desse arquivo (*commit*). É de
 fundamental importância que a mensagem de notificação, ou mensagem de
-*commit*, reflita as moficações feitas. São as mensagens que serão
+*commit*, reflita as modificações feitas. São as mensagens que serão
 consultadas quando você precisar desfazer/voltar. Ela deve ser curta (<=
 72 caracteres) e ao mesmo tempo informativa. A minha primeira mensagem
 não será, todavia.
@@ -276,7 +276,7 @@ git tag -d versao1
 ```
 
 Caso haja mudança no nome do arquivo que você esteja versionado, deve
-ser alterado pelo próprio git, para que fique no atual estágio de
+ser alterado pelo próprio Git, para que fique no atual estágio de
 versionamento.
 
 ```{r, engine = "bash", eval = FALSE}
@@ -368,9 +368,9 @@ cd meu1repo
 git diff
 ```
 
-Vamos aplicar o primeiro *add* ao `porqueLinux.txt` para que ele começe
+Vamos aplicar o primeiro *add* ao `porqueLinux.txt` para que ele comece
 a ser versionado. Perceba que ao adicioná-lo, as mudanças, no caso a
-criação do arquivo com contúdo, já são separadas para receber registro
+criação do arquivo com conteúdo, já são separadas para receber registro
 (*changes to be commited*).
 
 ```{r, engine="bash", echo=-c(1:2)}
@@ -395,12 +395,12 @@ git status
 ```
 
 Ainda resta o `REAMDE.txt` para receber registro. Você não precisa fazer
-agora. Pode continuar editanto caso não tenha atingido uma quantidade de
+agora. Pode continuar editando caso não tenha atingido uma quantidade de
 modificação merecedora de *commit*. Lembre-se que registros geram
 conteúdo no diretório `.git`. Quanto mais *commits*, mais conteúdo
 gerado. Mas também, toda vez que você faz um *commit*, você define um
 ponto de retorno, um estado salvo, caso precise no futuro
-recuperar/visitar. O que é uma unidade de modificação comitável você irá
+recuperar/visitar. O que é uma unidade de modificação "comitável" você irá
 definir aos poucos com a prática.
 
 ```{r, engine="bash", echo=-c(1:2)}
@@ -444,7 +444,7 @@ Instruímos o Git mostrar as diferenças para um *commit* atrás. A cabeça
 *HEAD* (cabeça) pois considera-se um crescimento do histórico debaixo
 para cima no qual um novo *commit* é colocado em cima dos demais
 (empilhado). O `HEAD@{0}` ou apenas `HEAD` representa o último registro
-feito. Não é necessário escrever o último `HEAD` na intrução abaixo.
+feito. Não é necessário escrever o último `HEAD` na instrução abaixo.
 
 Agora inspecionado uma distância de 2 *commits* a partir do último. Aqui
 tem-se os dois arquivos envolvidos nesse intervalo de 2 *commits*. Com
@@ -491,7 +491,7 @@ git status
 
 O Git sugere você aplicar *add* para preparar para *commit*. Caso as
 modificações sejam um engano e não mais desejadas, você pode
-desfazazê-las, abadonar a correção/inclusão das palavras usando
+desfazê-las, abandonar a correção/inclusão das palavras usando
 `checkout`. Vamos aplicá-lo para ver como funciona.
 
 ```{r, engine="bash", echo=-c(1:2)}
@@ -561,7 +561,7 @@ O `diff` vazio compara o diretório de trabalho com o último registro
   * `HEAD^n`
   * `HEAD~n`
 
-em que `n` é um número inteiro não negativo. Cada sulfixo tem uma
+em que `n` é um número inteiro não negativo. Cada sufixo tem uma
 finalidade que não detalharemos agora. Visite: [git-caret-and-tilde][].
 
 ```{r, engine="bash", echo=-c(1:2)}
@@ -595,7 +595,7 @@ git diff HEAD@{2} HEAD@{0}
 
 Para ficar claro daqui em diante, você pode ao invés de pedir `log`,
 pedir o `reflog` que incluí as referências em termos da sequência do
-mais rencente para os seus ancestrais.
+mais recente para os seus ancestrais.
 
 ```{r, engine="bash", echo=-c(1:2)}
 cd meu1repo
@@ -638,12 +638,12 @@ recebe versões funcionais do projeito, livre de bugs.
   \begin{center}
     \includegraphics [width=8cm]{./images/git_workflow.png}
   \end{center}
-  \caption{\textit{Printscreen} do passo 8}
+  \caption{Exemplo de esquema de ramificação de um projeto Git}
   \label{fig:cap03_work}
 \end{figure}
 
 
-Para criar um ramo, usandos `git branch` seguido do nome que se
+Para criar um ramo, usamos `git branch` seguido do nome que se
 deseja. Vamos criar um ramo para adicionar mais arquivos ou modificações
 ao projeto.
 
@@ -696,7 +696,7 @@ partir do ramo que é seu ancestral, ou seja, ele começa a partir do
 último *commit* existente, por padrão. Vamos adicionar um arquivo e
 commitar. O comando `wget` permite baixar arquivos pelo terminal. Será
 baixado um arquivo com um função para calcular o fator de inflação de
-variância (*vif*, variance inflation factor) usado em modelos de
+variância (*vif*, _variance inflation factor_) usado em modelos de
 regressão, disponível na página da Professora Suely
 Giolo\footnote{\url{http://people.ufpr.br/~giolo/CE071/Exemplos/vif.R}}.
 
@@ -1028,7 +1028,7 @@ No nosso projeto temos o *master* e o *feature01* em igual condição, sem
 nenhuma diferença. O *commit* recém feito indica um novo seguimento a
 partir daquele onde adicionamos novos itens na lista. Vamos criar um
 novo ramo porque atualmente estamos em um ramos suspenso (*detached
-HEAD*) que não é persistênte.
+HEAD*) que não é persistente.
 
 ```{r, engine="bash", echo=-c(1:2)}
 cd meu1repo
@@ -1057,8 +1057,8 @@ git log --graph --oneline --decorate --date=relative --all
 
 Vamos explorar bem a funcionalidade. Vamos voltar para o `feature01` e
 criar mais coisas lá. Você já deve estar pensando que tudo isso é
-absurdo e jamais alguém firaria indo e voltando assim. Você está certo,
-porém, quando o projeto envolve mais pessoas, cerrtamente as coisas irão
+absurdo e jamais alguém ficaria indo e voltando assim. Você está certo,
+porém, quando o projeto envolve mais pessoas, certamente as coisas irão
 bifurcar em algum ponto.
 
 ```{r, engine="bash", echo=-c(1:2)}
@@ -1184,7 +1184,7 @@ criar um ramo novo, modificar o arquivo na última linha e commitar. Vou
 voltar par ao *master* e fazer o mesmo mas vou usar um texto diferente
 para incluir no arquivo. Já que os ramos *feature01* e *feature02* não
 são mais necessários, podemos removê-los. No entanto, eles permanecem na
-história do projeto e poder resurgir se você voltar no tempo.
+história do projeto e poder ressurgir se você voltar no tempo.
 
 ```{r, engine="bash", echo=-c(1:2)}
 cd meu1repo
@@ -1370,12 +1370,12 @@ less bib1.txt | head -10
 ```
 
 Então deu conflito e o Git informa que ele deve ser resolvido. Resolver
-o conflito aqui significa abrir os arquivos com problema listados no git
-status e editar de tal forma a desconflitar. Nas regiões de conflito o
+o conflito aqui significa abrir os arquivos com problema listados no Git
+status e editar de tal forma a "desconflitar". Nas regiões de conflito o
 Git sinaliza de forma especial, indicando por divisórias (`<<<<<<<`,
 `=======` e `>>>>>>>`) as versões no HEAD (ramo *master*) e no ramos a
 ser incorporado (*feature03*). Então vamos resolver o conflito sem
-favorecer ninguém, ou seja, vamos encurtar para 4 digitos e manter caixa
+favorecer ninguém, ou seja, vamos encurtar para 4 dígitos e manter caixa
 alta. Dessa forma o aquivo fica assim.
 
 ```{r, engine="bash", echo=-c(1:2), include=FALSE}
diff --git a/cap04.Rmd b/cap04.Rmd
index 44cc1d6..38200c8 100644
--- a/cap04.Rmd
+++ b/cap04.Rmd
@@ -24,7 +24,7 @@ vários segmentos sejam conduzidos de forma independente e no futuro,
 quando apropriado, reunidos em um único *branch*. Isso é exatamente o
 que precisamos para trabalhar em equipe, certo? Se cada colaborador
 pudesse ter um ramo separado do projeto para trabalhar, todos poderiam
-trabalhar simultâneamente. Quando oportuno, bastaria fazer merges para
+trabalhar simultaneamente. Quando oportuno, bastaria fazer merges para
 reunir o trabalho. A questão é: como deixar o projeto disponível para os
 colaboradores?
 
@@ -37,7 +37,7 @@ desktop do *escritório*.
 
 O repositório remoto serve de centro do seu repositório Git. Como ele
 está em um servidor que você tem acesso, você pode compartilhar o
-repositório com outras máquinas, clonado de lá. Ele serve como *backup*
+repositório com outras máquinas, clonando de lá. Ele serve como *backup*
 do repositório.
 
 Aqui não se trabalha em colaboração mas o processo permite acessar o
@@ -66,7 +66,7 @@ Caso queira, você também pode usar `git init`. A diferença entre eles é
 só onde ficam os arquivos do versionamento. Com `git init`, um diretório
 oculto `.git/` é o repositório Git e os arquivos de trabalho, como o
 `README.md`, ficam ao lado dele na estrutura de diretório. Com `git
---bare init` o conteúdo do repositório Git fica na raíz. Essa última
+--bare init` o conteúdo do repositório Git fica na raiz. Essa última
 opção é justamente para criar repositórios remotos que vão justamente
 manter a parte repositório e não os arquivos.
 
@@ -98,7 +98,7 @@ git remote -v
 ```
 
 Esse endereço pode ter IP, porque na realidade, todo servidor tem um
-IP. Por exemplo, o servidor do <github.com> tem o IP
+IP. Por exemplo, o servidor do `github.com` tem o IP
 192.30.252.129. Para saber o IP é só dar um *ping* no endereço.
 
 ```{r, engine="bash", eval=FALSE}
@@ -319,7 +319,7 @@ No comando acima é possível visualizar o remoto padrão **origin** (URL
 SSH para onde será possível enviar os seus arquivos).
 
 **Exemplo:** para retornar o nome dos repositórios com a URL onde foram
-armazanados:
+armazenados:
 
 ```{r, engine="bash", echo=TRUE, eval=FALSE}
 git remote -v
@@ -445,10 +445,10 @@ não contém um diretório de trabalho.
 ```
 
 Acima foi criado um repositório limpo `MeuRepo.git`, no qual está
-armazenada a cópia de todos os arquivos do diretorio Git.
+armazenada a cópia de todos os arquivos do diretório Git.
 
 Após este primeiro passo o repositório limpo será colocado no Servidor e
-configurado os protolocos.  No exemplo abaixo, supondo que você tem
+configurado os protocolos.  No exemplo abaixo, supondo que você tem
 configurado um servidor `git.servidor.com`, e um diretório `/dir/git`no
 qual você quer armazenar seus repositórios. Ao copiar o seu repositório
 limpo, você pode configurar seu novo repositório.
@@ -501,7 +501,7 @@ necessário escrever um título para a sua nova chave, no campo `key`
 colar o texto copiado do arquivo `id_rsa.pub` e adicionar sua nova
 chave.
 
-Para checar a configuração da sua máquina com o sevidor basta realizar o
+Para checar a configuração da sua máquina com o servidor basta realizar o
 seguinte comando:
     
 **Exemplo:**
diff --git a/cap05.Rmd b/cap05.Rmd
index 612eb36..8583899 100644
--- a/cap05.Rmd
+++ b/cap05.Rmd
@@ -26,12 +26,12 @@ No capítulo anterior vimos como configurar um repositório remoto em um
 servidor. Esse procedimento possibilita trabalho em equipe pois
 centraliza o repositório remoto em um servidor que todos têm
 acesso. Assim, todos podem clonar, criar branches, subir as
-contruibuições, etc.  Apesar do servidor centralizar o trabalho de todos
+contribuições, etc.  Apesar do servidor centralizar o trabalho de todos
 os usuários, estes terão que se comunicar e fazer a gestão de tarefas
-sobre o projeto de outra forma, como por email direto, lista de
+sobre o projeto de outra forma, como por e-mail direto, lista de
 emails/discussão ou chats coletivos. Para que um desenvolvedor veja o
 que os outros fizeram, ele terá que periodicamente dar `fetch`, ver os
-braches do repositório, navegar no histórico de commits, ver *diffs*
+branches do repositório, navegar no histórico de commits, ver *diffs*
 entre arquivos. Se por um lado existe recurso para um fluxo de
 desenvolvimento orientado dessa forma, também existem recursos para
 tornar o trabalho coletivo mais simples e centralizado. Eles são os
@@ -39,7 +39,7 @@ serviços web para projetos Git.
 
 O Git tem vários serviços web voltados para ter um local que centralize 
 o projeto bem como ofereça recursos administrativos e colaborativos. 
-Esses serviços possuem contas *free*, algums planos pagos e diversos
+Esses serviços possuem contas *free*, alguns planos pagos e diversos
 recursos para todo tipo de projeto e equipe.
 
 Os objetivos desse capítulo são: apresentar os serviços web para
@@ -83,12 +83,12 @@ mesmo sendo desconhecidas. Dentre os principais recursos disponíveis,
 têm-se:
 
   * README: é um arquivo que funciona como capa do seu repositório. O
-    seu conteúdo é texto escrito em liguagem de marcação (Markdown, RST,
+    seu conteúdo é texto escrito em linguagem de marcação (Markdown, RST,
     Textile, Org, etc) renderizada para exibição pelo GitHub. Como capa,
     o conteúdo do README está na *home* do projeto e serve para informar
     o visitante dos objetivos do repositório, seus desenvolvedores,
     instruções de instalação/uso e formas de colaboração.
-  * Wiki: a Wiki de cada repositório são um conjunto de páginas que
+  * Wiki: a Wiki de cada repositório é um conjunto de páginas que
     serve para divulgação e documentação do repositório. Estas também
     são escritas em linguagem de marcação, tornando fácil e rápida a
     escrita pelo desenvolvedor e simples para o visitante ler e
@@ -100,11 +100,11 @@ têm-se:
     gerenciamento de tarefas. Os usuários criam *issues* para notificar
     um *bug* encontrado de forma que ele possa ser rapidamente
     corrigido. Criar *issues* também serve como ferramenta de
-    admistração de tarefas nas quais eles descrevem algo a ser
+    administração de tarefas nas quais eles descrevem algo a ser
     feito por alguém.
   * *Milestones*: são pedras de milha, ou seja, marcam um ponto a ser
     alcançado. São usadas para descrever o que precisa ser desenvolvido
-    para que ocorra uma mundança de versão e estabalecer um prazo para
+    para que ocorra uma mudança de versão e estabelecer um prazo para
     conclusão, por exemplo. As *milestones* agrupam *issues* que indicam
     as etapas a serem percorridas.
   * *Pull request* ou *merge request* (MR): é uma requisição de
@@ -113,7 +113,7 @@ têm-se:
     responsável por avaliar o MR pode ver os *diffs* nos arquivos e
     fazer o merge direto pela interface, de dentro do serviço sem
     precisar baixar (*fetch*) o ramo, aplicar o merge (*merge*) e
-    subí-lo (*push*). Então os desenvolvedores não precisam interromper
+    subi-lo (*push*). Então os desenvolvedores não precisam interromper
     o trabalho local para fazer um merge já que ele pode ser feito no
     serviço sem modificações no *workspace*.
   * *Fork*: é uma forma de se fazer uma cópia do projeto de alguém para
@@ -130,7 +130,7 @@ Finley\footnote{\url{http://techcrunch.com/2012/07/14/what-exactly-is-github-any
 mantenedor recebe um MR ele pode ver o perfil do contribuidor onde estão
 listados todos os projetos no qual este contribuiu. Ao aceitar o MR, é
 acrescentado mais uma colaboração a reputação do colaborador. Esse
-mecanísmo, então, beneficia as duas partes.
+mecanismo, então, beneficia as duas partes.
 
 Além dessas características chave, o GitHub permite que você acompanhe
 (*watch*) e favorite (*star*) repositórios. Também dá para seguir
@@ -153,7 +153,7 @@ coleções de funções que podem ser carregadas com um `source()`.
 Com o plano *free* do GitHub, você pode ter inúmeros repositórios
 públicos, inúmeros colaboradores, ter o *fork* de quantos repositórios
 quiser e participar de quantas organizações precisar. Para ter
-repositórios privados, o plano mais básico custa U$ 7 e dá direito à 5
+repositórios privados, o plano mais básico custa U$ 7 por mês e dá direito à 5
 repositórios. Existem outros planos individuais, e também planos
 organizacionais, para todos os tamanhos de projeto e equipe. Além dessas
 opções, pode-se ter o GitHub em um servidor próprio, o GitHub
@@ -179,7 +179,7 @@ básico.  O GitLab e o Bitbucket estão entre os 5 mais populares e
 permitem, por exemplo, ter alguns repositórios privados com a conta
 *free*.
 
-Como hopedamos nossos projetos coletivos do PET-Estatística no GitLab do
+Como hospedamos nossos projetos coletivos do PET-Estatística no GitLab do
 C3SL\footnote{\url{https://gitlab.c3sl.ufpr.br/explore}}, não podemos
 deixar de falar sobre ele.
 
@@ -187,9 +187,9 @@ deixar de falar sobre ele.
 
 O GitLab\footnote{\url{https://about.gitlab.com/}}, assim como o GitHub,
 é um serviço web para repositórios Git. O GitLab é um projeto *open
-source* desenvolvido em Ruby que teve início em 2011 pelo ucrâniano
+source* desenvolvido em Ruby que teve início em 2011 pelo ucraniano
 Dmitriy Zaporozhets. Em 2013, a Companhia GitLab tinha uma equipe de 11
-funcionios e mais de 10 mil organizações usando o serviço.
+funcionários e mais de 10 mil organizações usando o serviço.
 
 <!-- \begin{wrapfigure}{r}{0.4\textwidth} -->
 \begin{figure}[h]
@@ -200,8 +200,8 @@ funcionios e mais de 10 mil organizações usando o serviço.
 \end{figure}
 <!-- \end{wrapfigure} -->
 
-O GitLab, além de ser um serviço gratuito (com planos extras)
-colaboração, é também um programa que você pode instalar em servidor
+O GitLab, além de ser um serviço gratuito (com planos extras), é também 
+um programa que você pode instalar em servidor
 local para ter seus repositórios na intraweb. Esse é o caso do GitLab do
 C3SL e do GitLab do LEG\footnote{\url{http://git.leg.ufpr.br/explore}}.
 
@@ -228,7 +228,7 @@ Geoinformação). Estes GitLabs dão suporte à colaboração em código dentro
 dos departamentos de Informática e Estatística para alunos e professores
 (C3SL) e para a equipe e colaboradores do LEG.
 
-Em termos finaceiros, custa menos um servidor na nuvem da Digital
+Em termos financeiros, custa menos um servidor na nuvem da Digital
 Ocean\footnote{\url{https://www.digitalocean.com/community/tutorials/how-to-use-the-gitlab-one-click-install-image-to-manage-git-repositories}}
 com o GitLab CE (U$ 5/mês) do que ter uma conta para repositórios
 privados no GitHub (U$ 7/mês) por 5 repositórios privados). No entanto,
@@ -240,35 +240,35 @@ Além das características essenciais e comuns aos demais serviços, como
 5 níveis de acesso aos repositórios (*owner*, *master*, *developer*,
 *report* e *guess*), 2) revisão comentada de código nos *diffs*, 3)
 importação repositórios de outros serviços, 4) adição de *web hooks*
-e 5) integração contínua nativa apartir da versão 8.0.
+e 5) integração contínua nativa a partir da versão 8.0.
 
 # Criar um perfil #
 
-Criar uma conta no Github é tão simples como uma conta de email ou numa
+Criar uma conta no Github é tão simples como uma conta de e-mail ou numa
 rede social. Acesse o endereço <https://github.com/join> para preencher
 seus dados pessoais e escolher um plano. Nenhum dos planos tem limitação
 quanto ao número de repositórios ou colaboradores. O que muda é a
-quantidade de reposiórios privados. No plano *free*, só são criados
+quantidade de repositórios privados. No plano *free*, só são criados
 repositórios públicos enquanto que nos planos pagos, o menor deles
-permite 5 repositórios privados por um custo de U$ 5 por mês. Acesse
+permite 5 repositórios privados por um custo de U$ 7 por mês. Acesse
 <https://github.com/pricing> para mais detalhes.
 
-Ao preencher o formulário de criação de conta, você receberá um email
-com uma ulr de ativação. Se optar por planos pagos, terá que informar o número
+Ao preencher o formulário de criação de conta, você receberá um e-mail
+com uma url de ativação. Se optar por planos pagos, terá que informar o número
 do cartão de crédito para que seja feito o pagamento mensalmente.
 
 Para criar uma conta gratuita no GitLab, acesse 
 <https://gitlab.com/users/sign_in>. Os serviços GitLab que usamos são
 instalações em servidoras próprias (do C3SL e do LEG), no entanto, a
-interface do usuário é a mesma, com excessão de alguns privilégios
+interface do usuário é a mesma, com exceção de alguns privilégios
 administrativos.
 
 ## Habilitar comunição ##
 
-http://www.vogella.com/tutorials/GitHosting/article.html
+<!-- http://www.vogella.com/tutorials/GitHosting/article.html -->
 
-Geração e configuração das chaves públicas.
-Incluir screenshots.
+<!-- Geração e configuração das chaves públicas. -->
+<!-- Incluir screenshots. -->
 
 Uma vez criada uma conta, é necessário habilitar a comunicação entre sua
 máquina e o (servidor do) GitHub. A comunicação é feita com protocolo
@@ -328,7 +328,7 @@ qual você tem autenticação por chaves.
 Acesse <https://github.com/settings/ssh> para então adicionar chaves
 públicas (Figura \ref{github_sshkeys}) ao seu perfil. Clique em
 \menu{Add SSH key}, cole o conteúdo copiado do arquivo `*.pub` no campo
-`key`. No campo `Title` identifique a máquina correspndente àquela
+`key`. No campo `Title` identifique a máquina correspondente àquela
 chave. Use, por exemplo, `laptop` ou `trabalho` para facilitar o
 reconhecimento. É comum trabalhar-se com mais de um máquina, como uma em
 casa e outra no trabalho.
@@ -343,7 +343,7 @@ casa e outra no trabalho.
   \label{github_sshkeys}
 \end{figure}
 
-Para testar a comunição entre o GitHub e a sua máquina, execute:
+Para testar a comunicação entre o GitHub e a sua máquina, execute:
 ```{r, engine="bash", eval=FALSE}
 ## Testa comunição. Retorna um "Welcome!" em caso positivo.
 ssh -T git@github.com
@@ -354,7 +354,7 @@ ssh -vT git@github.com
 
 No GitLab, o cadastro de chaves públicas é um processo semelhante. Uma
 vez autenticado, acesse <https://gitlab.c3sl.ufpr.br/profile/keys> para
-adicionar chaves públicas.  Para testar a comunição entre o GitLab e a
+adicionar chaves públicas.  Para testar a comunicação entre o GitLab e a
 sua máquina, execute:
 
 ```{r, engine="bash", eval=FALSE}
@@ -405,7 +405,7 @@ repositório e serve para documentar o seu objetivo, formas de
 colaboração, colaboradores, formas de instalação/uso.
 
 Você pode editar o arquivo `README.md` (ou qualquer outro) no próprio
-GitHub. As moficações que fizer devem ser *commitadas* para serem
+GitHub. As modificações que fizer devem ser *commitadas* para serem
 salvas. O arquivo `README.md`, que é linguagem de marcação MarkDown, é
 automaticamente renderizado pelo GitHub fazendo com que *urls* sejam
 clicáveis e códigos estejam em ambientes de fonte monoespaço, além de
@@ -460,7 +460,7 @@ git push -u origin master
 O seu projeto é configurado em \menu{Settings}. Para renomear, deletar
 ou transferir o projeto para outro usuário ou organização, vá em
 \menu{Options}. Em \menu{Collaborators} você administra os colaboradores
-do projeto. Para genrenciar os ramos de trabalho, como proteger ou
+do projeto. Para gerenciar os ramos de trabalho, como proteger ou
 remover ramos, vá em \menu{Branches}. O uso de de serviços web é
 configurado no \menu{Webhooks \& services}. O \menu{Deploy keys} permite
 adicionar chaves públicas.
@@ -581,11 +581,11 @@ descrever o procedimento de trabalho considerando tais interfaces.
 
 # Fluxo de trabalho #
 
-TODO Deixar os chunks dessa sessão reproduzíveis! TODO
+<!-- TODO Deixar os chunks dessa sessão reproduzíveis! TODO -->
 
 O fluxo de trabalho de um projeto Git local usando um servidor remoto
 foram apresentados no capítulo anterior. O fluxo com um repositório Git
-mantido em um serviço, como o GitHub ou Gitlab, não muda muito. A maior
+mantido em um serviço, como o GitHub ou GitLab, não muda muito. A maior
 diferença não é sobre o uso de novas instruções Git mas sim a adoção de
 uma estratégia de trabalho (*workflow*) baseada nos recursos desses
 serviços, como as *milestones* e *issues*. Esse modelos de trabalho
@@ -596,7 +596,7 @@ acrescenta àqueles necessários para se comunicar com o
 repositório. Alguns desses comandos, senão todos, já foram apresentados
 no capítulo anterior a esse.
 
-Ao considerar um seviço web, você pode começar um repositório novo de
+Ao considerar um serviço web, você pode começar um repositório novo de
 duas formas: localmente ou pelo serviço.
 
 Pelo serviço, qualquer que seja, crie um novo repositório. GitHub e
@@ -608,7 +608,7 @@ de criar e *clonar* o repositório e também de criar local e adicionar a
 *url* do repositório remoto (`origin`).
 
 Localmente o repositório segue o ciclo normal de desenvolvimento que
-minimamente contém as intruções `git add` e `git commit`. Os fluxos de
+minimamente contém as instruções `git add` e `git commit`. Os fluxos de
 trabalho, em geral, preconizam o desenvolvimento a partir de *branches*
 de demanda cujo conteúdo será incorporado aos ramos permanentes
 (`master`, `devel`) quando forem concluídos. Abaixo ilustramos a
@@ -677,7 +677,7 @@ default. No entanto, um projeto Git pode ter mais de um repositório
 remoto. Considere o caso simples de um repositório para arquivos de uma
 disciplina. Esse repositório contém tanto lista de exercícios para os
 alunos como também as provas com as soluções. Para não entregar as
-provas de bandeija, o diretório de provas existe no ramo `secret` e é
+provas de bandeja, o diretório de provas existe no ramo `secret` e é
 enviado somente para um repositório privado chamado `provas`. Já o
 conteúdo restante (lista de exercícios, notas de aula, scripts),
 disponibilizado para os alunos, fica no ramo `master`, mantido em um
@@ -736,7 +736,7 @@ após o `fetch`. Para transferir o conteúdo `origin/devel` para o
 `devel` tem-se que usar o `git merge`. No entanto, sempre que haver
 necessidade, antes do *merge* pode-se verificar as diferenças que
 existem entre local e remoto, principalmente quando esse remoto traz
-contribuições de algum colaborador. Os comandos abaixos exibem as
+contribuições de algum colaborador. Os comandos abaixo exibem as
 diferenças entre os ramos e aplicam o merge entre eles.
 
 ```{r, engine="bash", eval=FALSE}
@@ -765,7 +765,7 @@ git pull origin
 git pull origin devel
 ```
 
-Por fim, para subir o trabalho feito em um ramo, usa-se a intrução `git
+Por fim, para subir o trabalho feito em um ramo, usa-se a instrução `git
 push`. Enviar o seu trabalho com frequência é a melhor forma de ter
 *backups*, exibir e disponibilizar suas contribuições para os seus
 colaboradores. A documentação do `git
@@ -810,7 +810,7 @@ disponibilizar seu trabalho. No entanto, um dos principais objetivos dos
 serviços web é permitir a colaboração entre pessoas. Já mencionamos o
 básico sobre recursos de colaboração quando falamos de *issue*, *fork* e
 *merge request*. Nas sessões a seguir, vamos nos aprofundar nesses três
-mecanísmos chave para a colaboração via serviços web para Git.
+mecanismos chave para a colaboração via serviços web para Git.
 
 ## Issues ##
 
@@ -825,7 +825,7 @@ que as pessoas abram um assunto/tópico referente ao projeto. Em geral,
 com os *issues* as pessoas externas ao projeto indicam um *bug* - uma
 falha a ser corrigida - ou sugerem que o projeto incorpore determinada
 característica desejável. O dono do projeto avalia a proposta e pode
-discutí-la logo em seguida, mantendo as mensagens reunidas e disponíveis
+discuti-la logo em seguida, mantendo as mensagens reunidas e disponíveis
 para outros usuários que acompanham o projeto. Quando a proposta do
 *issue* for implementada, o *issue* é fechado. Mesmo assim, o *issue*
 continua disponível e pode ser referenciado no futuro, tanto para novos
@@ -884,7 +884,7 @@ Com o *fork* você pode colaborar como um terceiro em um projeto, ou
 seja, sem ser colaborador adicionado pelo dono. Nessa cópia você tem
 permissões de *owner* pois na realidade, embora seja uma cópia, ela é
 toda sua. Você faz sua cópia livre, trabalha como quiser e no prazo que
-quiser, e submete ao projeto original o desenvido na sua cópia. O dono
+quiser, e submete ao projeto original o desenvolvido na sua cópia. O dono
 do projeto não tem como saber por que você fez o *fork* (mas você pode
 criar um *issue*) nem quando irá concluir o que almeja. No entanto,
 quando concluir, para que seu trabalho seja incorporado ao original,
@@ -935,14 +935,14 @@ git push origin issue#33
 ```
 
 Na interface web, o membro faz um *merge request* desse ramo para um
-ramo permamente, no qual em projetos simples é o *master* mas em
+ramo permanente, no qual em projetos simples é o *master* mas em
 projetos maiores é usualmente o *devel*. Ao clicar em *merge request*,
 uma caixa de diálogo abre para que você liste as colaborações que o
 *branch* leva.
 
 Em ambos os serviços, o *merge resquest* leva para um página na qual
 você escolhe que ramo de demanda (doador) será incorporado a um ramo
-permamente (receptor). Ao confirmar os ramos envolvidos, tem-se uma
+permanente (receptor). Ao confirmar os ramos envolvidos, tem-se uma
 caixa de texto destinada as informações sobre quais as modificações
 devem ser incorporadas. Elas servem para justificar, esclarecer e
 informar o responsável pelo *merge* sobre a incorporação. Quando o
@@ -967,13 +967,13 @@ e portanto, o trabalho vai levar mais tempo.
 Os próprios serviços web fazem o *merge* diretamente quando não existe
 conflito (merge do tipo *fast forward*). Isso facilita bastante o
 trabalho. Porém, não haver conflito de *merge* não significa que as
-modificações incorparadas estão funcionais, ou seja, as modificações
+modificações incorporadas estão funcionais, ou seja, as modificações
 feitas precisam ser testadas localmente para verificar se surtiram
 efeito. É possível habilitar o serviço Git para checar se o projeto é
-executável ou funcional. Esse recurso se chama intergração contínua e
+executável ou funcional. Esse recurso se chama integração contínua e
 veremos na próxima sessão.
 
-Em caso de confito de *merge*, tem-se que baixar os ramos (`git
+Em caso de conflito de *merge*, tem-se que baixar os ramos (`git
 fetch`). Localmente pode-se comparar as diferenças entre eles para
 entender as fontes de conflito. Para isso são recomendáveis as
 interfaces para Git que serão discutidas no próximo Capítulo. Uma vez
@@ -1028,7 +1028,7 @@ aperfeiçoá-lo mas o tempo todo estamos sujeitos a fazer modificações que
 induzem erros e alguém encontra erros não esperados (*bugs*).
 
 Monitorar erros no projeto em desenvolvimento não é uma tarefa fácil,
-principalmente em trabalhos coletivos nos quais cada colaborator tem um
+principalmente em trabalhos coletivos nos quais cada colaborador tem um
 ambiente de trabalho. Em uma situação ideal, alguém teria que testar se
 o projeto corre sem erros (código executa, software instala) em uma
 máquina cliente (com os requisitos mínimos exigidos), toda vez que um
@@ -1062,24 +1062,24 @@ IC\footnote{\url{https://about.gitlab.com/gitlab-ci/}} são:
   3) Verificação em vários ambientes (sistemas operacionais,
      arquiteturas, dependências e versões);
   4) Informação coletiva e imediata à equipe da causa de falha na hora
-     que ela ocorre, o que aumenta a visilibidade, facilita a
+     que ela ocorre, o que aumenta a visibilidade, facilita a
      comunicação e direcionamento de esforços.
   5) Indicação de sucesso ou não na home do projeto e nos *branches*
      disponível antes do merge;
   6) Entrega de versões estáveis, documentação e arquivos acessórios com
      *continuous deployment*, o que facilita o empacotamento e
-     disponibização do projeto.
+     disponibilização do projeto.
   7) Custo computacional reduzido já que é feito em um servidor
      dedicado.
   8) Acaba saindo mais barato do que parar o projeto para corrigir um erro.
 
-O que deve ficar claro é que a integração contínua não elinima erros,
+O que deve ficar claro é que a integração contínua não elimina erros,
 mas faz com que eles sejam mais fáceis de identificar e corrigir.
 
 Sem a automação, os espaços entre verificações podem ficar longos.
 Encontrar um *bug* em tantos *commits* é mais difícil, encontrar no
 código é mais ainda. Pode atrasar a entrega do projeto e comprometer a
-receita e popularidade. Integrações periodicas são mais fáceis e leves.
+receita e popularidade. Integrações periódicas são mais fáceis e leves.
 
 O fluxo de trabalho de um repositório com IC é basicamente assim:
 
@@ -1089,15 +1089,15 @@ O fluxo de trabalho de um repositório com IC é basicamente assim:
   3) O serviço de IC monitora o repositório toda vez que modificações
      ocorrem;
   4) O serviço de IC corre todos os testes de inspeção que foram
-     configurados (instala dependendencias, executa scripts,
-     cria/tranfere arquivos, etc);
+     configurados (instala dependências, executa scripts,
+     cria/transfere arquivos, etc);
   5) O serviço de IC disponibiliza produtos da verificação, como
      binários de instalação e documentação (no caso de sucesso) ou log
-     de execussão (no caso de falha);
+     de execução (no caso de falha);
   6) O serviço de IC assinala no repositório Git o *status* da
      verificação: sucesso/fracasso;
   7) O serviço de IC informa a equipe dos resultados por mensagem de
-     email ou *web hooks*, como o Slack;
+     e-mail ou *web hooks*, como o Slack;
   8) A equipe toma das providências cabíveis na primeira oportunidade,
      como corrigir a falha ou anunciar o sucesso;
   9) O serviço aguarda por mais modificações;
@@ -1114,7 +1114,7 @@ Para vincular um projeto no GitHub com IC no Travis CI, você precisa
 logar no <https://travis-ci.org/> com a sua conta do GitHub. Assim que
 você logar, dê autorização para acessar seus repositórios e em uma lista
 você deve marcar os que usarão o serviço.  A próxima etapa é criar um
-arquivo `.travis.yml` na raíz do seu repositório Git. Esse arquivo
+arquivo `.travis.yml` na raiz do seu repositório Git. Esse arquivo
 oculto especifica todas as instruções que devem ser feitas a fim de
 verificar seu repositório. Se seu repositório é um pacote R, por
 exemplo, esse arquivo vai ter instruções de instalação do pacote.
@@ -1127,7 +1127,7 @@ prática em ver exemplos em uso, como o `.travis.yml` dos pacotes R
 `devtools`\footnote{\url{https://github.com/hadley/devtools}} que estão
 na lista dos mais utilizados.
 
-Para todas as liguagens e objetivos têm-se exemplos de arquivos
+Para todas as linguagens e objetivos têm-se exemplos de arquivos
 `.trevis.yml`. Para o Emacs e bibliotecas lisp visite
 <https://github.com/rolandwalker/emacs-travis>,
 <https://github.com/Malabarba/elisp-bug-hunter> e
@@ -1168,7 +1168,7 @@ realidade um *desktop* com Ubuntu Server 14.04. É patrimônio da UFPR de
 responsabilidade do LEG mas tem uso compartilhado com o PET Estatística
 e colaboradores do Laboratório. Desde a disponibilização do GitLab, em
 julho de 2015, mantemos artigos, materiais de ensino (aulas, provas,
-scripts), tutoriais e materias de blog em devolvimento colaborativo,
+scripts), tutoriais e matérias de blog em devolvimento colaborativo,
 além de pacotes R.
 
 Nessa servidora, criamos um usuário chamado `gitlab-runner` com o qual
@@ -1186,7 +1186,7 @@ pacotes R.
 A documentação oficial sobre como usar o arquivo `.gitlab-ci.yml`
 encontra-se em <http://doc.gitlab.com/ce/ci/yaml/README.html>.
 
-O arquivo `.gitlab-ci.yml` fica na raíz do projeto. Seu conteúdo define
+O arquivo `.gitlab-ci.yml` fica na raiz do projeto. Seu conteúdo define
 todo o processo de verificação do seu repositório a partir de uma série
 de instruções, como execução de comandos diretos ou execução de
 scripts. Abaixo tem-se um exemplo simples de `.gitlab-ci.yml`.
@@ -1202,7 +1202,7 @@ job2:
 ```
 
 Neste exemplo existem dois *jobs* (tarefas). Cada um deles corre
-independente e podem ser executados simultâneamente. O primeiro executa
+independente e podem ser executados simultaneamente. O primeiro executa
 um *script* shell e o segundo comandos *shell* em uma lista. Porém, tais
 arquivos podem ser bem mais complexos, com campos além do `script:`. Os
 campos a seguir são todos opcionais:
@@ -1211,7 +1211,7 @@ campos a seguir são todos opcionais:
     *docker*\footnote{\url{https://www.docker.com/}}. O tutorial de Alan
     Monger considera esse campo.
   * `services`: também refere ao *docker*. Tais campos são de uso menos
-    frequênte, porém existe uma série de vantagens neles. A documentação
+    frequente, porém existe uma série de vantagens neles. A documentação
     oficial sobre isso encontra-se em
     <http://doc.gitlab.com/ce/ci/docker/README.html>.
   * `before_script`: define comandos/scripts a serem executados antes
@@ -1240,14 +1240,14 @@ campos a seguir são todos opcionais:
       script: "compacta_transfere.sh"
       stage: entrega
     ```  
-  * `variables`: serve para criar variaveis de ambiente que podem ser
+  * `variables`: serve para criar variáveis de ambiente que podem ser
     usados por todos os comandos e scripts. Tais variáveis podem
-    aramazenas senhas de acesso, necessárias por exemplo para instalação
+    armazenadas senhas de acesso, necessárias por exemplo para instalação
     de componentes e acesso à bancos de dados.
   * `cache`: indica os diretórios e arquivos que serão mantidos entre os
     *jobs* (builds), possivelmente porque são aproveitados futuramente.
 
-Com excessão dos nomes listados acima, um *job* pode ter qualquer nome,
+Com exceção dos nomes listados acima, um *job* pode ter qualquer nome,
 desde que seja exclusivo. Dentro de um *job* tem-se também uma lista de
 campos disponíveis para configurá-lo:
 
@@ -1257,7 +1257,7 @@ campos disponíveis para configurá-lo:
     execução dos *jobs*. Vários *jobs* podem ser do mesmo estágio e
     nesse caso são executados paralelamente.
   * `only` e `except`: servem para restringir a execução do *job*,
-    incluindo ou excluindo, para uma lista de referências git, como
+    incluindo ou excluindo, para uma lista de referências Git, como
     *branches* ou *tags*. Esse campo permite expressões regulares, úteis
     para incluir (excluir) ramos representáveis por *regex*, como são os
     ramos de desenvolvimento do nosso workflow, iniciados com *issue*.
@@ -1281,7 +1281,7 @@ campos disponíveis para configurá-lo:
       estágio anterior falhou.
     * `on_success`: são instruções executadas quando todos os *jobs* do
       estágio anterior foram bem sucedidos.
-    * `always`: excutados sempre.
+    * `always`: executados sempre.
   * `cache`: especifica arquivos e diretórios mantidos entre um *job* e
     outro.
 
@@ -1302,7 +1302,7 @@ job_R:
 Estas são instruções em *shell* que chamam o R com expressões passadas
 para `Rscript -e` para fazer a instalação do pacote. Na ocorrência da
 primeira falha, o processo é logicamente interrompido e os
-colaboradoradores podem ver a causa em
+colaboradores podem ver a causa em
 <http://git.leg.ufpr.br/leg/legTools/builds>. No caso do *build* correr
 sem falhas, tem-se uma estampa de *success*. Essa estampa também vai
 aparecer no `README.md` na página de rosto do projeto, basta para isso
@@ -1321,7 +1321,7 @@ meio do GitLab CI. Um *runner* pode ser específico de um projeto ou pode
 ser um *runner* compartilhado, disponível à todos os projetos. Estes
 últimos são úteis à projetos que tem necessidades similares, como todos
 àqueles projetos que são pacotes R, por exemplo. Isso facilita a
-administação e atualização. Os específicos, por outro lado, atendem
+administração e atualização. Os específicos, por outro lado, atendem
 projetos com demandas particulares.
 
 Apenas usuários com permissões de *admin* podem criar *runners*
@@ -1336,9 +1336,9 @@ novas entradas no menu da esquerda:
      útil para passar senhas.
   * *Triggers*: servem para TODO
   * *CI Web Hooks*: esse *web hook* pode ser usado para criar eventos
-    quando o *build* é concluido.
+    quando o *build* é concluído.
   * *CI Settings*: configurações gerais.
-  * *CI Services*: permite integrar o CI com outros serviços, como email
+  * *CI Services*: permite integrar o CI com outros serviços, como e-mail
     e Slack.
 
 Para habilitar um *runner*, é necessário instalar o
diff --git a/cap06.Rmd b/cap06.Rmd
index fe2e468..b8551af 100644
--- a/cap06.Rmd
+++ b/cap06.Rmd
@@ -165,7 +165,7 @@ interface `git gui`.
 \end{figure}
 
 A interface `git gui` se apresenta de forma simples, o que facilita sua
-utilização. Na figura \ref{fig:gitgui} detacamos as quatro áreas que
+utilização. Na figura \ref{fig:gitgui} destacamos as quatro áreas que
 compreendem a interface. Na primeira porção temos listados os arquivos
 presentes no *working directory*, os arquivos criados aparecem com ícone
 em branco e os modificados com linhas em azul, aqui a interface
@@ -220,7 +220,7 @@ Git, uma vez que visualizar de forma gráfica as alterações que os
 comandos realizados causam no projeto, torna mais fácil a compreensão
 dos mesmos.
 
-`gitk`, assim como a `git gui` pode ser chamada atráves da linha de
+`gitk`, assim como a `git gui` pode ser chamada através da linha de
 comando:
 
 ```{r, engine="bash", eval=FALSE}
@@ -246,7 +246,7 @@ chamada neste estado do repositório temos:
 Perceba na figura \ref{fig:gitk} que esta interface é mais completa do
 que a `git gui` no que diz respeito à informação. Dividida em apenas
 duas partes, a `gitk` apresenta na primeira todo o histórico do projeto,
-comtempla uma implementação visual e agradável do comando `git log
+contempla uma implementação visual e agradável do comando `git log
 --graph`. No gráfico apresentado na parte superior, as bolinhas em azul
 representam *commits* passados, a de amarelo indica o estado atual do
 repositório e em vermelho são as modificações no *working directory*. Ao
@@ -261,7 +261,7 @@ Além da excelente apresentação visual do repositório Git, a interface
 `gitk` também permite algumas alterações. Clicando com o botão direito
 de seu *mouse* em qualquer *commit* listado, podemos criar *tags*,
 reverter o repositório neste estado, criar um ramo a partir do *commit*
-dentre outras opções possíveis atráves da interface.
+dentre outras opções possíveis através da interface.
 
 ## Outras Interfaces ##
 
@@ -322,7 +322,7 @@ opções do menu quando pressionado o botão direito do mouse.
 \end{landscape}
 
 Na figura \ref{fig:rabbit} temos o *screenshot* do repositório
-`meu1repo` no navegor de arquivos `nautilus` (padrão do sistema Ubuntu
+`meu1repo` no navegador de arquivos `nautilus` (padrão do sistema Ubuntu
 14.04). Perceba que com essa interface os ícones de arquivos e pastas no
 navegador ganham destaque com um outro pequeno ícone na parte
 inferior. Estes pequenos ícones indicam o estado do arquivo sem precisar
@@ -373,7 +373,7 @@ seja por meio de *plugins* adicionais instalados ou pela opção nativa do
 editor.
 
 Destacamos aqui dois editores, comumente utilizados pela comunidade
-estatística, que possuem os comandos **Git** intergrado à sua
+estatística, que possuem os comandos **Git** integrados à sua
 interface. São eles, o `emacs`, o qual temos as opções de *buffers* no
 editor onde podemos abrir uma instância *shell* e executar os comandos
 **Git** junto com o desenvolvimento do código fonte. Além disso uma
@@ -455,7 +455,7 @@ velhos tempos antes de conhecermos o **Git**).
   \begin{center}
     \includegraphics{./images/meld2}
   \end{center}
-  \caption{\textit{Screenshot} de comparaçao de arquivos com programa
+  \caption{\textit{Screenshot} de comparação de arquivos com programa
   \textit{meld} 
   \texttt{RabbitVCS}}
   \label{fig:meld2}
@@ -468,7 +468,7 @@ projeto `meu1repo`, iniciado no capítulo 3 e alterado na seção
 foram salvas, então podemos visualizá-las no `meld`. A inicialização do
 programa pode ser feita via linha de comando `git difftool`, só temos
 que informar o programa a ser utilizado com a opção `-t` (abreviação de
-`--tool`). Nos sistemas UNIX, o programa pode ser lançado apenas atráves
+`--tool`). Nos sistemas UNIX, o programa pode ser lançado apenas através
 do nome `meld`.
 
 ```{r, engine="bash", eval=FALSE}
@@ -518,7 +518,7 @@ git difftool README.md
 Na figura \ref{fig:meld3} temos o _screenshot_ do programa após executado
 o `difftool`. Nesta figura temos a mesma informação trazida pelas
 interfaces onde implementam o comando `git diff`, porém aqui podemos
-alterar os arquivos exibidos atráves das flechas nas bordas (levando ou
+alterar os arquivos exibidos através das flechas nas bordas (levando ou
 trazendo as contribuições) ou mesmo editando pela interface. Isso pode
 ser útil caso necessite desfazer parcialmente um *commit*, ou seja,
 parte das alterações de uma versão anterior seria mantida e parte
@@ -654,12 +654,12 @@ git add README.txt
 git commit -m "Resolve conflito via meld"
 ```
 
-Para resolucão de conflitos via alguma ferramenta gráfica com o comando
+Para resolução de conflitos via alguma ferramenta gráfica com o comando
 `git mergetool`, o **Git** gera arquivos de _backup_ com extensão
 `.orig`. Perceba no _output_ gerado pelo `git status` que estes
 armazenam o conteúdo de cada arquivo em conflito com as porções
 conflitantes.  É recomendável não versionar estes arquivos de
-_backup_. Podemos então simplesmente exluí-los ou ignorá-los após a
+_backup_. Podemos então simplesmente excluí-los ou ignorá-los após a
 mesclagem adicionando arquivos com esta extensão no `.gitignore`. Outra
 forma de manter seu repositório sem os arquivos _backup_ é configurando
 sua `mergetool` para não armazená-los, ou seja, que a própria ferramenta
@@ -719,7 +719,7 @@ para \textit{download} em
 \url{https://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools}},
 como outras interfaces de comparação bastante utilizadas em projetos
 versionados. Em geral, todos estes programas seguem o mesmo estilo de
-exbição de arquivos que o `meld` e as configurações para torná-los
+exibição de arquivos que o `meld` e as configurações para torná-los
 programas de `mergetool` e `difftoll` padrão são as mesmas.
 
 É importante salientar que as ferramentas gráficas apresentadas neste
diff --git a/cap07.Rmd b/cap07.Rmd
index 35d87d3..8dd7569 100644
--- a/cap07.Rmd
+++ b/cap07.Rmd
@@ -73,7 +73,7 @@ inicial de todo repositório. Por esse motivo, é importante que o
     para softwares).  Criando esse arquivo com estas informações, ele
     aparecerá automaticamente em uma aba na página inicial do projeto.
 
-Outra parte fundamental do git, são os **commits**. Além de salvarem as
+Outra parte fundamental do Git, são os **commits**. Além de salvarem as
 alterações realizadas nos arquivos, também são responsáveis por
 documentar as alterações feitas por qualquer usuário e em qualquer
 arquivo.  Os commits agilizam o processo de revisão do projeto, e poderá
@@ -85,7 +85,7 @@ aparecerão no `git log` do projeto,por isso é essencial que sejam bem
 escritas, de forma clara e sigam um padrão.
 
 Algumas **regras de ouro**, que são convenções gerais, para que um
-projeto versionado com git seja bem sucedido são:
+projeto versionado com Git seja bem sucedido são:
 
   - **Faça commits regularmente**: isso faz com que as mudanças de
     código entre um commit e outro sejam menores, tornando mais fácil
@@ -106,7 +106,7 @@ projeto versionado com git seja bem sucedido são:
 
 Existem outras convenções estabelecidas sobre como escrever mensagens de
 commit contextualizadas, baseadas nas mensagens geradas por mensagens de
-funções do próprio git. Estas convenções podem resumidas nas 7 regras
+funções do próprio Git. Estas convenções podem resumidas nas 7 regras
 que são convenções globais:
 
   1. **Separe o título do corpo do texto com uma linha em branco**: por
@@ -130,7 +130,7 @@ que são convenções globais:
      mensagens de commits únicas. O modo imperativo significa escrever
      como se estivesse dando um comando a alguém. Seja direto e
      objetivo, e escreva no presente.  Exemplos de mensagens no
-     impertativo:
+     imperativo:
      
 
          - Adiciona versão final
@@ -145,7 +145,7 @@ que são convenções globais:
 
   6. **Limite o corpo da mensagem em 72 caracteres**: ao escrever uma
      mensagem de commit mais longa, devemos manter o corpo da mensagem
-     com no máximo 72 carateres.
+     com no máximo 72 caracteres.
   7. **Use o corpo da mensagem para explicar "o que" e "porque", e não
      "como"**: contextualize o que você fez e o motivo. Na maioria dos
      casos você pode deixar de fora como você fez as modificações, pois
@@ -156,7 +156,7 @@ que são convenções globais:
 A escolha do *workflow* (fluxo de trabalho) depende de cada projeto e
 das preferências pessoais. Podemos utilizar as informações sobre cada
 *workflow*, e decidir qual é mais adequado para cada projeto. Existem
-quatro maneiras principais de trabalhar em colaboração com o git e o
+quatro maneiras principais de trabalhar em colaboração com o Git e o
 GitLab:
 
 ## Centralized workflow ##
@@ -236,7 +236,7 @@ habilitada faça o merge desse branch `freature` para o branch `master`.
 Dessa forma, evita-se os possíveis conflitos e garante que tais
 alterações não causaram algum problema. Esse workflow é altamente
 recomendado por ser simples de gerenciar, evitar grandes conflitos, e
-ser relativamente fácil para usuários novos do git.
+ser relativamente fácil para usuários novos do Git.
 
 **Exemplo**
 
@@ -283,7 +283,7 @@ funções específicas.  Todo o desenvolvimento é realizado no branch
 `release`, onde é testada e finalmente incorporada ao ramo master, que
 contém apenas versões finais (estáveis). É extremamente recomendado esse
 workflow para desenvolvimento de softwares, porém exige de mais
-familiaridade com o git. Permite, por exemplo, que os usuários de um
+familiaridade com o Git. Permite, por exemplo, que os usuários de um
 software, instalem tanto uma versão estável (do branch `master`) quanto
 uma versão em desenvolvimento (do branch `develop`).
 
diff --git a/cap08/cap08_cs.Rmd b/cap08/cap08_cs.Rmd
index 9558471..056b4c0 100644
--- a/cap08/cap08_cs.Rmd
+++ b/cap08/cap08_cs.Rmd
@@ -13,10 +13,10 @@ Configura o diretório atual para um projeto Git
 Configura o nome que será visualizado nos commit
 
 #### $ git config --global user.email "Seu email"
-Configura o email que será associado ao seu nome
+Configura o e-mail que será associado ao seu nome
 
 #### $ git clone git://github.com/usuario/projeto.git
-Clona um projeto git já existente
+Clona um projeto Git já existente
 
 ### Atividades Locais
 
@@ -104,4 +104,4 @@ Desfaz todos os commit a partir do commit especificado
 Reverte para um commit especificado
 
 #### $ git submodule
-Cria, atualiza ou inspeciona um submodulo (sub branch)
+Cria, atualiza ou inspeciona um submódulo (sub branch)
diff --git a/cap08/cap08_dt.Rmd b/cap08/cap08_dt.Rmd
index 2b840d9..79d8a29 100644
--- a/cap08/cap08_dt.Rmd
+++ b/cap08/cap08_dt.Rmd
@@ -14,7 +14,7 @@ output:
 ## Config ##
 
 O `config` é um comando usado para ajustar as configurações padrão do
-git.  Há duas configurações básicas a serem feitas: a inclusão do e-mail
+Git.  Há duas configurações básicas a serem feitas: a inclusão do e-mail
 e do nome do usuário Git.  Todas as configurações definidas como globais
 ficam armazenadas em um arquivo chamado `.gitconfig`, que fica
 localizado no diretório padrão do usuário.
@@ -33,7 +33,7 @@ git config --global user.email ezio.auditore@exemple.com
 (chave assimétrica). Essa criptografia torna o processo de transferência
 de arquivos entre o cliente e o servidor mais segura.
 
-Para que o git local consiga se conectar a um servidor git remoto, é
+Para que o Git local consiga se conectar a um servidor Git remoto, é
 necessário que esta chave seja gerada e que as devidas configurações
 sejam feitas tanto localmente quanto no servidor remoto, caso contrário,
 é exibido um erro e a conexão é interrompida.
@@ -57,8 +57,8 @@ git status --help
 
 ## Repositório ##
 
-Um repositório é uma pasta gerenciada pelo git. A partir da criação
-desta, usufruimos dos sistema de versionamento, sendo possível transitar
+Um repositório é uma pasta gerenciada pelo Git. A partir da criação
+desta, usufruímos do sistema de versionamento, sendo possível transitar
 entre as diferentes versões a medida que necessário.
 
 **Exemplo:**
@@ -146,8 +146,8 @@ git commit -m "Meu primeiro commit"
 Os `branchs` são como uma cópia dos arquivos do ultimo commit para um
 ambiente de desenvolvimento paralelo, o que permite que as modificações
 em um `branch` não afete os arquivos em outro.  Os branchs também são
-chamados de ramos de desenvolvimento. Veja com mais detalhes no
-capitulos dos worksflows.
+chamados de ramos de desenvolvimento. Veja com mais detalhes nos
+capítulos 3 e 7.
 
 **Exemplo:**
 ```{r, engine='bash', echo=TRUE, eval=FALSE}
@@ -187,7 +187,7 @@ git merge novoBranch
 ## Rm ##
 
 O `git rm`, na sua forma mais comum, serve para remover um arquivo de
-forma que ele deixe de ser gerenciado pelo git e seja excluido do disco
+forma que ele deixe de ser gerenciado pelo Git e seja excluído do disco
 rígido. Também é possível que o arquivo deixe de ser gerenciado e
 permaneça no disco.
 
@@ -258,7 +258,7 @@ git pull origin
 `HEAD` é um arquivo que contém um apontador para o `branch` atual.
 Quando o `checkout` é executado para a mudança do `branch`, esse arquivo
 é automaticamente modificado, apontando agora para o novo local, e assim
-permitindo que, quando o computador for desligado e depois de reniciado
+permitindo que, quando o computador for desligado e depois de reiniciado
 o Git ainda esteja trabalhando com o mesmo `branch`.
 
 ## Tag ##
@@ -301,7 +301,7 @@ git stash list
 
 Enquanto o `git checkout` somente transita entre os `commits`, o `reset`
 pode também alterar o histórico, fazendo `commits` serem apagados de
-maneira irreversível (--hard) ou serem apenas resetados ao estado de não
+maneira irreversível (--hard) ou serem apenas retornados ao estado de não
 commitado (--soft).
 
 **Exemplo:**
-- 
GitLab