diff --git a/cap08/cap08_dt.Rmd b/cap08/cap08_dt.Rmd
index 1dde0fa571a3964db7d39c412d006c5a86d1edc6..0fc178f0d095c38ba44ab51cb3cfc46070cc3aff 100644
--- a/cap08/cap08_dt.Rmd
+++ b/cap08/cap08_dt.Rmd
@@ -6,9 +6,9 @@ Dicionário de Termos
 
 ## Config
 
-O `config` é um comando usado para ajustar as configurações padrão do git.
+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 e 
-do nome do usuário git.
+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.
@@ -24,7 +24,7 @@ git config --global user.email ezio.auditore@exemple.com
 ## SSH Key
 
 É uma chave de autenticação baseada em criptografia de chave pública
-(chave assimétrica). Essa criptografia torna o processo transferência 
+(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, é 
@@ -41,7 +41,7 @@ ssh-keygen
 
 ## Help
 
-Todo comando git tem um manual de ajuda que pode ser exibido na tela
+Todo comando Git tem um manual de ajuda que pode ser exibido na tela
 com o comando `--help`.
 
 **Exemplo:**
@@ -52,9 +52,9 @@ git status --help
 
 ## Repositório
 
-Um repositório é uma pasta gerenciada pelo git. A partir da criação deste,
+Um repositório é uma pasta gerenciada pelo Git. A partir da criação deste,
 podemos marcar pontos de mudanças significativas nos arquivos gerenciados,
-sendo possível transitar entre as diferentes verões a medida do necessário.
+sendo possível transitar entre as diferentes versões.
 
 **Exemplo:**
 ```{r, engine='bash', eval=FALSE}
@@ -64,19 +64,17 @@ git init
 
 ## Stagin Area
 
-A stagin area é um espaço temporário na pasta gerenciada pelo git. É 
-aonde ficam os arquivos antes de ser marcados como uma versão definitiva. 
-Em tradução livre, stagin area é area de estágio, 
-podemos assim imaginar que o arquivo está estagiando antes de
-ser promovido a um arquivo definitivo.
+A stagin area é um espaço temporário na pasta gerenciada pelo Git. É 
+o local em que ficam os arquivos antes de serem marcados como uma versão 
+definitiva. Em tradução livre, stagin area é área de estágio, podemos 
+assim imaginar que o arquivo está estagiando antes de ser promovido a um 
+arquivo definitivo.
 
 ## Remote
 
-O `remote` mostra o servidor remoto aonde o
-seus arquivos git estão hospedados. O remote padrão
-geralmente é criado com o nome de `origin`, mas
-é possível adiciona-lo utilizando outros nomes e 
-até mesmo adicionar outros servidores remotos juntamente ao `origin`.
+O `remote` mostra o servidor remoto onde os arquivos Git estão hospedados. 
+O remote padrão geralmente é criado com o nome de `origin`, mas é possível adicioná-lo utilizando outros nomes e até mesmo adicionar outros servidores
+remotos juntamente ao `origin`.
 
 **Exemplo:**
 ```{r, engine='bash', eval=FALSE}
@@ -92,8 +90,8 @@ disponível em um servidor remoto para o servidor local.
 Depois da clonagem, estará disponível todos os arquivos e todo o 
 histórico de controle de versões sem a necessidade de uso da internet.
 
-É importante salientar que quando é usado o `clone`, o servidor remoto
-é adicionado automaticamente, podendo ser acessado atravéz do nome 
+É importante salientar que quando se é usado o `clone`, o servidor remoto
+é adicionado automaticamente, podendo ser acessado através do comando
 `origin`.
 
 **Exemplo:**
@@ -107,7 +105,7 @@ git remote
 ## Status
 
 O status exibe a diferença entre o estado atual dos arquivos e o estado
-do ultimo `commit` do mesmo `branch`. São três estados possíveis:
+do último `commit` do mesmo `branch`. São três estados possíveis:
 consolidado (committed), modificado (modified) e preparado (staged).
 
 **Exemplo:**
@@ -129,10 +127,9 @@ git add *
 
 ## Commit
 
-O `commit` marca os arquivos da stagin area como uma
-versão definitiva, para que posteriormente, caso algum erro ocorra, 
-possamos voltar para commits anteriores onde o código está 
-em pleno funcionamento.
+O `commit` marca os arquivos da stagin area como uma versão definitiva, 
+para que posteriormente, caso algum erro ocorra, possamos voltar nos 
+commits anteriores onde o código está em pleno funcionamento.
 
 **Exemplo:**
 ```{r, engine="bash", echo=TRUE, eval=FALSE}
@@ -141,9 +138,9 @@ git commit -m "Meu primeiro commit"
 
 ## Branch
 
-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` são como cópias dos arquivos do último commit para um ambiente 
+de desenvolvimento paralelo, o qual 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.
 
 **Exemplo:**
@@ -155,7 +152,7 @@ git branch novoBranch
 ## Checkout
 
 O `checkout` serve para transitar entre branchs e commits. 
-Usando o checkout é possivel voltar a commits anteriores.
+Usando o checkout é possível voltar a commits anteriores.
 
 **Exemplo:**
 ```{r, engine='bash', echo=TRUE, eval=FALSE}
@@ -165,10 +162,10 @@ git checkout teste
 
 ## Merge
 
-Com o `merge` é possivel a fusão dos dois ramos em um.
+Com o `merge` é possível a fusão de dos dois ramos em um.
 
 Quando se trabalha em ramos diferentes (diferentes branchs) e precisa-se
-posteriormente juntar o trabalho dos dois, o `merge` (fundir) é usado, 
+posteriormente juntar o trabalho, o `merge` (fundir) é usado, 
 permitindo que o trabalho seja centralizado novamente. A fusão é feita 
 de forma automática, mas conflitos podem ocorrer, como por exemplo,
 quando duas ou mais pessoas modificam a mesma parte do código. 
@@ -183,14 +180,13 @@ git merge novoBranch
 
 ## Rm
 
-O `git rm`, na sua forma mais comum, serve para remover um arquivo de 
-forma que ele deixe de sergerenciado pelo git e seja excluido do disco 
-rígido. Também é possível que o arquivo deixe de ser gerenciado 
-e permaneça no disco.
+O `git rm`, de forma mais prática, serve para remover um arquivo deixando
+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.
 
-Uma das vantagens é que, quando o arquivo é removido pelo `git rm`, ele 
-já aparece como preparado (staged), precisando somente que 
-a exclusão seja commitada.
+Uma das vantagens é que, quando o arquivo é removido pelo `git rm`, já 
+aparece como preparado (staged), precisando somente que a exclusão seja 
+commitada.
 
 **Exemplo:**
 ```{r, engine='bash', echo=TRUE, eval=FALSE}
@@ -203,10 +199,9 @@ git rm --cached teste.tex
 
 ## Mv
 
-O `git mv` move ou renomeia arquivos, informando ao git que eles foram
-movidos ou renomeados.
+O `git mv` move ou renomeia arquivos informando ao Git.
 
-Caso a mudança seja feita sem esse comando o git entende que o arquivo
+Caso a mudança seja feita sem esse comando, o Git entende que o arquivo
 foi deletado e que um novo arquivo foi criado, deixando de fora, 
 por exemplo, a ligação existente entre o arquivo e seus commits.
 
@@ -229,10 +224,8 @@ git push origin master
 
 ## Fetch 
 
-O `fetch` busca no repositório remoto os dados e arquivos que
-não estão no repositório local. É impostante frisar que o `fetch` não 
-faz o merge dos arquivos, deixando isso para ser feito manualmente 
-pelo usuário.
+O `fetch` atualiza o repositório local com as alterações do remoto, porém
+não realiza o merge dos arquivos, deixando isso para ser feito manualmente.
 
 **Exemplo:**
 ```{r, engine='bash', echo=TRUE, eval=FALSE}
@@ -257,10 +250,9 @@ 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, permitindo que, quando o computador for desligado e depois
-ligado novamente, o git ainda esteja trabalhando com o mesmo `branch`
-de antes.
+esse arquivo é automaticamente modificado, apontando agora para o
+novo local, e assim permitindo que, quando o computador for desligado e 
+depois de reniciado o Git ainda esteja trabalhando com o mesmo `branch`.
 
 ## Tag
 
@@ -269,10 +261,10 @@ Geralmente são usadas para marcar versões definitivas, como a v1.0, v2.0
 e assim por diante.
 
 Elas são divididas em dois tipos: leve e anotada.
-A `tag` leve simplemente aponta para um `commit` específico, já a `tag` 
-anotada é guardada como objtos inteiros, possuindo algumas informações
-relacionadas a ela, como o nome da pessoa que criou, a data, uma mensagem
-semelhante a de `commit`, entre outras.
+A `tag` leve simplesmente aponta para um `commit` específico. Já a `tag` 
+anotada é guardada como objetos inteiros, possuindo algumas informações,
+como o nome da pessoa que criou, a data, uma mensagem semelhante a de `commit`, 
+entre outras.
 
 **Exemplo:**
 ```{r, engine='bash', echo=TRUE, eval=FALSE}
@@ -285,8 +277,8 @@ git tag -a v1.0 -m "Minha primeira tag anotada."
 
 ## Stash
 
-É uma maneira de não precisar fazer um `commit` para mudar de `branch`.
-Executando este comando, os arquivos modificados ficam salvos em uma
+Com este comando não é necessário fazer um `commit` para mudar de `branch`.
+Ao executá-lo, os arquivos modificados ficam salvos em uma
 pilha de modificações inacabadas, sendo possível transitar entre
 `branchs` e voltar ao trabalho inacabado quando necessário.
 
@@ -302,25 +294,25 @@ 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 
+apagados de maneira irreversível (--hard) ou serem apenas resetados 
 ao estado de não commitado (--soft).
 
 **Exemplo:**
 ```{r, engine='bash', echo=TRUE, eval=FALSE}
-# Apagando o ultimo commit (Voltando ao anterior):
+# Apagando o último commit (voltando ao anterior):
 git reset --hard HEAD~1
 ```
 
 
 ## Rebase
 
-O `rebase` é usado para modificar `commits` antigos. Ele refaz a arvore
-de `commits`, sendo assim, não é uma boa ideia fazer um `push` da 
-alteração, pois modificara a arvore do servidor, afetando todos os 
+O `rebase` é usado para modificar `commits` antigos. Ele refaz a árvore
+de `commits`, sendo assim não é uma boa ideia fazer um `push` da 
+alteração, pois modificará a árvore do servidor afetando todos os 
 desenvolvedores.
 
-A idéia geral é que ele pega os commits de um ramo e "muda de base", 
-passando-os para novos commits do ramo atual, formando uma arvore com
+A ideia geral é `rebase` apaga os commits de um ramo e "muda de base", 
+passando-os para novos commits do ramo atual, formando uma árvore com
 fluxo de trabalho linear.
 
 **Exemplo:**
@@ -332,8 +324,8 @@ git rebase teste
 ## Blame
 
 Pesquisa qual `commit` modificou determinado arquivo, com o objetivo
-de encontrar quem inseriu um erro e quando foi inserido.
- Esse método também e chamado de anotação de arquivo.
+de encontrar quem e quando um erro foi inserido.
+Esse método também é chamado de anotação de arquivo.
 
 **Exemplo:**
 ```{r, engine='bash', echo=TRUE, eval=FALSE}
@@ -344,7 +336,7 @@ de encontrar quem inseriu um erro e quando foi inserido.
 
 O `bisect` realiza uma pesquisa binária (binary search) a procura de 
 erros. Para que a pesquisa ocorra, é necessário um ponto no tempo em que 
-no `commit` esteja tudo funcionando e um em que não esteja.
+o código esteja funcionando e outro que não esteja.
 
 **Exemplo:**
 ```{r, engine='bash', echo=TRUE, eval=FALSE}
@@ -355,4 +347,4 @@ git bisect start
 git bisect bad
 # Marcando o commit com nome commit1 como funcionando:
 git bisect good commit1 
-```
\ No newline at end of file
+```
diff --git a/cap08/cap08_er.Rmd b/cap08/cap08_er.Rmd
index b9c5eabf93f81fed4200751cb11485e410397c42..1ab51d297ebf2187ee49cf8ddf808a6efc9f3a6a 100644
--- a/cap08/cap08_er.Rmd
+++ b/cap08/cap08_er.Rmd
@@ -1,12 +1,59 @@
-## Clonar, Modificar e Enviar
+## Clonar, Modificar e Subir
 ```{r, engine='bash', echo=TRUE, eval=FALSE}
 # Clonar o projeto desta apostila:
 git clone git@gitlab.c3sl.ufpr.br:pet-estatistica/apostila-git.git
+
+# Modifique o projeto antes de executar o código abaixo.
+
+# Commitar o projeto:
+git commit -a -m "Sua Mensagem de Commit"
+# Enviar projeto ao servidor (branch master, servidor origin):
+git push origin master
+
+```
+
+## Resolver conflito de merge
+
+```{r, engine='bash', eval=FALSE, echo=TRUE}
+# Requisitar merge:
+git merge ramo_teste
+
+# Resolver conflitos manualmente.
+
+# Finalizar merge com o commit:
+git commit -a -m "Merge do ramo_teste"
+
+```
+
+## Incorporar o remoto ao local
+
+```{r, engine='bash', eval=FALSE, echo=TRUE}
+# Adicionando novo remote com nome remoto:
+git remote add remoto git@gitlab.c3sl.ufpr.br:pet-estatistica/apostila-git.git  
+
 ```
 
 ## Deletar Ramos
 
 ```{r, engine='bash', echo=TRUE, eval=FALSE}
+# Deletar ramo local:
 git branch -d "nome_ramo"
+# Deletar ramo remoto:
+git push origin :nome_ramo
+```
+
+## Criar ramo de um commit passado
+
+```{r, engine='bash', echo=TRUE, eval=FALSE}
+# Verificar código commit:
+git log
+# Criando branch com commit do código
+# ec3650c8661d75b486a236e3d416ab58db1d596a:
+git branch novo_branch ec3650c8661d75b486a236e3d416ab58db1d596a
+
+# Mudando para novo_branch
+git checkout novo_branch
+
 ```
 
+