Corrigido cap03.Rmd

cap03.Rmd

@@ -24,10 +24,10 @@ Neste capítulo, as instruções serão todas feitas no terminal mesmo que
 existam alternativas gráficas para as mesmas. Isso enfatiza no que está
 sendo feito além do fato de que no terminal todos devem ter os mesmos
 recursos e os comandos irão produzir os mesmos resultados, o que faz
-esse tutorial algo reproduzível. Casos você queira usufruir das
+desse tutorial algo reproduzível. Casos você queira usufruir das
 ferramentas gráficas vá para o capítulo 6.
 
-Sabendo que você executou os comandos de perfil que no capítulo
+Sabendo que você executou os comandos de perfil do capítulo
 anterior, temos o Git devidamente configurado, com credenciais (nome e
 e-mail) e configurações aplicadas. Vamos então ver como o sistema de
 controle de versão acontece.
@@ -81,7 +81,7 @@ cd meu1repo
 git <instrução> <complementos ...>
 ```
 
-Os comandos abaixo revelam tudo o Git possui, embora dizer o que ele tem
+Os comandos abaixo revelam tudo o que o Git possui, embora dizer o que ele tem
 não signifique nada diante do que ele pode fazer com o que tem.
 
 ```{r, engine="bash", echo=-c(1:2)}
@@ -102,7 +102,7 @@ git init
 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
+diretório. É por essa razão que ele é oculto. Alterar seu conteúdo pode
 prejudicar ou interromper o funcionamento do Git. Se você quiser
 encerrar o processo de versionamento fazendo com que esse diretório seja
 como qualquer outro diretório, é só excluir a diretório `.git/`. Cada
@@ -123,12 +123,12 @@ diretórios. Se você usa distribuição Debian, instale com `sudo apt-get
 install tree`. Windows: [tree][].
 
 Vamos começar da maneira mais simples: criando um arquivo com uma linha
-de texto apenas. Bem, vale avisar que ao longo desse capítulo, os
+de texto apenas. Vale ressaltar que ao longo desse capítulo, os
 arquivos serão sempre bem pequenos e dificilmente realistas, mas como o
-enfoque está no funcionamento, não haverá prejuízo.
+enfoque está no funcionamento não haverá prejuízo.
 
 Vamos criar o arquivo com conteúdo também pelo terminal. Se você
-preferir, abra eu editor de texto favorito (Emacs, Gedit, Geany,
+preferir, use um editor de texto de sua preferência (Emacs, Gedit, Geany,
 RStudio, Bloco de Notas, Notepad++, etc) e faça algo mais criativo.
 
 ```{r, engine="bash", echo=-c(1:2)}
@@ -170,10 +170,10 @@ traduzidos.
   \label{fig:cap03_pversion}
 \end{figure}
 
-De forma geral temos 3 estágios \ref{fig:cap03_pversion} de arquivos
+De forma geral temos 3 estágios (\ref{fig:cap03_pversion}) de arquivos
 considerados no sistema de controle de versionamento Git. São eles
-*working directory*, *Staged Area* e *Committed*, os discutiremos ao
-logo do texto. Todo arquivo criado em um diretório versionado deve
+*working directory*, *Staged Area* e *Committed*. Seus assuntos serão abordados 
+ao longo do texto. Todo arquivo criado em um diretório versionado deve
 necessariamente passar pelos três estágios. Voltando para a nossa
 situação temos o arquivo `README.txt` criado e atualmente ele está no
 estágio *working directory*, faremos todo o procedimento para que chegue
@@ -193,7 +193,7 @@ para serem registradas (*changes to be commited*). A melhor tradução de
 *commit*, pensando no seu uso em Git, é **fechar sob segurança**. Quando
 um *commit* é feito, cria-se um instante na linha do tempo que salva o
 estado do projeto. Para esse instante o projeto pode ser retrocedido,
-voltando o condição/conteúdo de todos os arquivos para o momento no qual
+voltando a condição/conteúdo de todos os arquivos para o momento no qual
 o mencionado *commit* foi feito. Você pode voltar para um *commit* de
 semanas e até anos atrás.
 
@@ -256,7 +256,7 @@ mesmo de projetos moderados ou grandes.
 # Complementos #
 
 Para o registro de desenvolvimento, existe marcação por tags, que 
-seriam commits especiais, geralmente usado para marcar pontos de 
+seriam commits especiais, geralmente usada para marcar pontos de 
 destaque do projeto, por exemplo versão alfa, beta, teste servidor.
 
 ```{r, engine = "bash", echo =-c(1:2), eval = FALSE} 
@@ -293,9 +293,7 @@ git rm README.txt
 # Versões de Arquivos Diferentes #
 
 Vamos criar mais arquivos e acrescentar conteúdo ao já rastreado pelo
-Git para percebermos o funcionamento. Escrever uma lista de razões para
-usar o Linux. Deixei a lista curta poder ampliar no futuro e com erros
-de português para corrigir depois.
+Git para percebermos o funcionamento.
 
 ```{r, engine="bash", echo=-c(1:2)}
 cd meu1repo
@@ -335,8 +333,8 @@ git status
 ```
 
 O Git retornou dois campos. No primeiro ele diz que existem mudanças no
-`README.txt` não encaminhadas para receber registro (*not staged for
-commit*) e no segundo ele aponta que o `porqueLinux.txt` é um arquivo
+'`README.txt`' não encaminhadas para receber registro (*not staged for
+commit*) e no segundo ele aponta que o '`porqueLinux.txt`' é um arquivo
 não rastreado (fora de monitoramento).
 
 Vamos explorar um pouco mais os recursos do Git antes de adicionar as
@@ -396,7 +394,7 @@ git status
 
 Ainda resta o `REAMDE.txt` para receber registro. Você não precisa fazer
 agora. Pode continuar editando caso não tenha atingido uma quantidade de
-modificação merecedora de *commit*. Lembre-se que registros geram
+modificações 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
@@ -439,14 +437,14 @@ cd meu1repo
 git diff HEAD@{1}
 ```
 
-Instruímos o Git mostrar as diferenças para um *commit* atrás. A cabeça
+Instruímos o Git a mostrar as diferenças para um *commit* atrás. A cabeça
 (*HEAD*) é o que se entende como estado mais recente. Usa-se o termo
 *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 instrução abaixo.
 
-Agora inspecionado uma distância de 2 *commits* a partir do último. Aqui
+Agora inspecionando uma distância de 2 *commits* a partir do último. Aqui
 tem-se os dois arquivos envolvidos nesse intervalo de 2 *commits*. Com
 `--name-only` retorna-se só o nome dos arquivos.
 
@@ -461,13 +459,11 @@ cd meu1repo
 
 git diff --name-only HEAD@{2} HEAD@{0}
 ```
-
-Vamos resolver logo o caso da palavra sem acento em
-`porqueLinux.txt`. Você abre o arquivo no seu editor de texto e modifica
-conforme necessário. A modificação compreende um linha apenas mas aí
-lembrei de mais coisas e acrescentei. O `git diff` mostra as
-diferenças. Epa! As diferenças não eram entre *commits*? O conteúdo
-adicionado ainda não recebeu notificação!
+Ao abrir um arquivo no seu editor de texto e modificá-lo conforme necessário, 
+tal modificação compreeenderá a uma linha apenas. Futuramente, ao acrescentar 
+novas informações, o git diff mostrará as diferenças. Em um primeiro momento, 
+vale ressaltar que as diferenças são entre os *commits* dado que o conteúdo 
+adicionado ainda não recebeu notificação.
 
 ```{r, engine="bash", include=FALSE}
 cd meu1repo
@@ -514,13 +510,13 @@ cd meu1repo
 less porqueLinux.txt
 ```
 
-Bateu o arrependimento? Tem formas de poder retroceder com mudanças
+Caso decida reverter a situação, existem formas de poder retroceder com mudanças
 ainda não registradas mas mantendo a possibilidade de
 recuperá-las. Mostraremos em breve.
 
 **NOTA**: sempre que quiser testar um comando novo e não está seguro do
 que ele faz ou da extensão dos seus efeitos, faça uma cópia do projeto
-em outro diretório e experimente ele lá. Isso previne sabores amargos,
+em outro diretório e experimente ele lá. Isso previne eventuais problemas,
 pois algumas ações podem ser irreversíveis.
 
 ```{r, engine="bash", echo=-c(1:2)}
@@ -842,8 +838,8 @@ git log --oneline
 ```
 
 É possível criar um ramo a partir de um *commit* ancestral ao
-atual. Isso é extremamente útil para resolver os bugs. Vamos fazer um
-segundo ramo a partir do *commit* anterior a inclusão do arquivo R.
+atual. Isso é extremamente útil para resolver os erros. Vamos fazer um
+segundo ramo a partir do *commit* anterior à inclusão do arquivo R.
 
 ```{r, engine="bash", echo=-c(1:2)}
 cd meu1repo
@@ -872,9 +868,7 @@ cd meu1repo
 ## O histório existente nesse ponto.
 git log --name-only --oneline
 ```
-
-Já que o *commit* mais recente dessa história aponta para o arquivo
-compras, vamos checar o seu conteúdo apenas por medida de segurança.
+Vamos conferir o conteúdo do *commit* mais recente.
 
 ```{r, engine="bash", echo=-c(1:2)}
 cd meu1repo
@@ -1027,7 +1021,7 @@ git log --graph --oneline --decorate --date=relative --all
 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
+novo ramo porque atualmente estamos em um ramo suspenso (*detached
 HEAD*) que não é persistente.
 
 ```{r, engine="bash", echo=-c(1:2)}
@@ -1131,7 +1125,7 @@ cd meu1repo
 git log --graph --oneline --decorate --date=relative --all
 ```
 
-Agora nos temos o *feature01* na frente do master e o *feature02* ao
+Agora nós temos o *feature01* na frente do master e o *feature02* ao
 lado. O conteúdo dos dois ramos terá que ser incorporado ao *master* em
 algum momento porque é assim que funciona. Mas não há razões para
 preocupação pois o propósito do Git é justamente facilitar esse
@@ -1184,7 +1178,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 ressurgir se você voltar no tempo.
+história do projeto e podem ressurgir se você voltar no tempo.
 
 ```{r, engine="bash", echo=-c(1:2)}
 cd meu1repo
@@ -1292,7 +1286,7 @@ git commit -m "Arquivo de experimento em BIB. Trunca cabeçalho 4 digitos."
 Baixamos e modificamos o arquivo. Adicionamos e fizemos o registro das
 modificações. Agora vamos voltar ao *master* e baixar o arquivo também,
 fazendo de conta que é outra pessoa trabalhando no mesmo projeto, mas
-essa pessoa vai passar a cabeçalho para caixa alta.
+essa pessoa vai passar o cabeçalho para caixa alta.
 
 ```{r, engine="bash", echo=-c(1:2)}
 cd meu1repo
@@ -1313,7 +1307,7 @@ cd meu1repo
 wget 'http://www.leg.ufpr.br/~walmes/data/bib1.txt'
 ```
 
-Ao encurtar o nome para quatro dígitos, fica assim.
+Ao encurtar o nome para quatro dígitos, o resultado é dado por:
 
 ```{r, engine="bash", echo=-c(1:2)}
 cd meu1repo
@@ -1369,7 +1363,7 @@ cd meu1repo
 less bib1.txt | head -10
 ```
 
-Então deu conflito e o Git informa que ele deve ser resolvido. Resolver
+Como podemos observar, 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
 Git sinaliza de forma especial, indicando por divisórias (`<<<<<<<`,