From 95ee1b0c74bc90a1f12b04011b4d5f3e3a1cd398 Mon Sep 17 00:00:00 2001
From: Eduardo Junior <edujrrib@gmail.com>
Date: Thu, 17 Dec 2015 17:37:25 -0200
Subject: [PATCH] =?UTF-8?q?Corrige=20ortografia=20dos=20documentos=20*.md?=
 =?UTF-8?q?=20renderizados=20pelo=20servi=C3=A7o=20web?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 CONTRIBUTING.md | 276 ++++++++++++++++++++++++------------------------
 plano.md        |  30 +++---
 2 files changed, 153 insertions(+), 153 deletions(-)

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 051ff87..48e113b 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,138 +1,138 @@
-Guia de contribuição
-====================
-
-Esse é um projeto público do PET Estatística aberto a
-colaboradores. Para que a colaboração seja bem sucedida, seguem algumas
-intruções e recomendações.
-
-## O funcionamento
-
-O núcleo do tutorial é o arquivo `git_tuto.Rmd`. O arquivo `Rmd` é
-marcado por ser escrito com sintaxe [markdown][] com fragmentos de
-código R. Os fragmentos de código R são interpretados durante a
-compilação feita com a função `render` do pacote [rmarkdown][]. Por ser
-escrito em markdown, o tutorial pode ser compilado em formatos como markdown (`.md`), html e PDF.
-
-Apesar de `Rmd` normalmente ter fragmentos de código R, nesse tutorial
-predominam fragmentos de código shell, em outras palavras, são
-fragmentos de código executados do terminal do Linux. Para ter um
-fragmento de código shell que seja interpretado na compilação, tem-se
-que fazê-lo conforme abaixo.
-
-    ```{r, engine="sh"}
-    comando shell
-    ```
-
-A compilação desse documento cria sempre um projeto Git do zero. Com
-intruções do shell ao longo do documento, no instante da compilação,
-arquivos são criados, adicionados (`git add`), commitados (`git
-commit`), moficados, etc. Esse documento é, portanto, um documento
-reproduzível.
-
-Para compilar o documento você deve abrir uma sessão R onde o diretório
-de trabalho é o que contém o arquivo `git_tuto.Rmd` e rodar uma chamada
-da função render. Usuários do RStudio podem fazer isso diretamente pelo
-botão de compilar, presente na barra de ferramentas.
-
-    ```{r, engine="sh"}
-    library(rmarkdown)
-
-    render("git_tuto.Rmd")
-    ```
-
-Os diretórios criados durante a compilação são sempre apagados, para que ao
-compilar novamente, tudo seja reproduzido. O projeto deve recriar tudo e
-é essa a intenção, apesar do custo. Se os diretórios não fossem
-deletados antes de uma nova compilação, iria-se receber erros de
-compilação.
-
-Esse documento usa instruções no terminal que podem ser particulares do
-Linux, como o comando `tree` e `sed`. Portando, a reprodutibilidade da
-compilação pode não acontecer em outros sistemas operacionais.
-
-## O fluxo de trabalho
-
-Esse projeto terá dois ramos persistentes:
-
-  * `devel`: que irá receber imediatamente a contribuição dos
-    membros e será submetido a teste (no caso compilação). Se bem
-    sucedido, a contribuição é movida para o ramo `master`.
-  * `master`: que recebe a versão estável do projeto.
-
-Os membros devem criar ramos de demanda para adicionarem suas
-contribuições. Por exemplo, se existe a demanda (*issue*) de acrescentar uma
-sessão sobre o uso do programa `meld` para resolver conflitos de merge,
-deve-se criar um ramo para isso, adicionar as contribuições e subir esse
-ramo para o repositório remoto. Os *issues* criados no GitLab são
-automaticamente numerados. Para nosso benefício, vamos usar o mesmo
-número ao criar os *branches* para atender as correspondentes
-demandas. Vamos usar o padrão `issue#?` em que `?` representa o número
-do *issue*.
-
-```sh
-git branch -b issue#3
-
-... trabalha, git add, git commit ...
-... trabalha, git add, git commit ...
-... trabalha, git add, git commit ...
-
-git push origin issue#3
-```
-
-Assim que der o `git push`, a próxima etapa é fazer uma requisição de
-*merge*. Isso se faz pela interface do GitLab clicando em
-[merge request][] no menu da esquerda, dentro da página do projeto, e
-depois no botão *New Merge Request*. Lá é onde se designa o responsável
-por avaliar e aplicar o *merge* e quais os *branches* envolvidos
-(doador/receptor).
-
-Existe apenas uma regra que jamais deve ser quebrada:
-
-> Nunca dê `push` para os ramos `devel` e `master`.
-
-Esses ramos se receberão conteúdo provenientes de *merge* dos ramos de
-demanda (*issue*).
-
-## Mensagens de commit
-
-É extremamente recomendado, por questões de organização e produtividade,
-que as mensagens de commit sejam apropriadas. Não use mensagens vagas ou
-óbvias do tipo *Modificações feitas*, *Arquivos incluídos*. Procure algo
-como *Incluí arquivo de estilo CSS*, *Modifica preâmbulo*, *Troca
-'require' por 'library'* ([5 dicas para melhores commits][]).
-
-Exitem formas especiais de escrever um *commit* que tenha ações do
-repositório remoto como fechar um *issue* ou fazer uma referência a
-outro *commit* ([ações nas mensagens de commit][]). As palavras
-especiais são: `close`, `closes`, `closed`, `fix`, `fixes`, `fixed`,
-`resolve`, `resolves`, `resolved`. Depois das palavras vem uma
-identificação de *issue* ou *sha1*.
-
-```sh
-git commit -m "Close #4. Bug devido ao encoding."
-```
-
-Visite para mais dicas de como escrever um *commit*:
-[como-escrever-boas-mensagens-de-commit][]
-
-## Escrita do código
-
-Recomensa-se fortemente que ao escrever o código, não se ultrapasse 72
-caracteres por linha. Isso torna o texto/código mais legível nos
-arquivos fontes. Linhas longas são difíceis de ler nos monitores atuais, 
-que possuem uma tela grande.
-
-Editores de texto (de verdade) geralmente possuem formas de auto quebrar
-linhas, auto indentar/acomodar ou sinalizar a margem direita. O Emacs
-tem [auto break lines][] e [refluxo de texto][]. Outros editores
-permitem exibir uma linha vertical para indicar o limite, como o RStudio
-(> Tools > Global Options > Code > Display > Margin column).
-
-[markdown]: http://br-mac.org/2013/09/o-que-e-markdown.html
-[rmarkdown]: http://rmarkdown.rstudio.com/
-[merge request]: https://gitlab.c3sl.ufpr.br/pet-estatistica/git-tutorial/merge_requests
-[ações nas mensagens de commit]: https://help.github.com/articles/closing-issues-via-commit-messages/
-[5 dicas para melhores commits]: https://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message
-[auto break lines]: http://emacswiki.org/emacs/LineWrap
-[refluxo de texto]: http://www.emacswiki.org/emacs/FillParagraph
-[como-escrever-boas-mensagens-de-commit]: http://blog.diovani.com/post/101092814586/como-escrever-boas-mensagens-de-commit
+Guia de contribuição
+====================
+
+Esse é um projeto público do PET Estatística aberto a
+colaboradores. Para que a colaboração seja bem sucedida, seguem algumas
+instruções e recomendações.
+
+## O funcionamento
+
+O núcleo do tutorial é o arquivo `git_tuto.Rmd`. O arquivo `Rmd` é
+marcado por ser escrito com sintaxe [markdown][] com fragmentos de
+código R. Os fragmentos de código R são interpretados durante a
+compilação feita com a função `render` do pacote [rmarkdown][]. Por ser
+escrito em markdown, o tutorial pode ser compilado em formatos como markdown (`.md`), html e PDF.
+
+Apesar de `Rmd` normalmente ter fragmentos de código R, nesse tutorial
+predominam fragmentos de código shell, em outras palavras, são
+fragmentos de código executados do terminal do Linux. Para ter um
+fragmento de código shell que seja interpretado na compilação, tem-se
+que fazê-lo conforme abaixo.
+
+    ```{r, engine="sh"}
+    comando shell
+    ```
+
+A compilação desse documento cria sempre um projeto Git do zero. Com
+instruções do shell ao longo do documento, no instante da compilação,
+arquivos são criados, adicionados (`git add`), commitados (`git
+commit`), modificados, etc. Esse documento é, portanto, um documento
+reproduzível.
+
+Para compilar o documento você deve abrir uma sessão R onde o diretório
+de trabalho é o que contém o arquivo `git_tuto.Rmd` e rodar uma chamada
+da função render. Usuários do RStudio podem fazer isso diretamente pelo
+botão de compilar, presente na barra de ferramentas.
+
+    ```{r, engine="sh"}
+    library(rmarkdown)
+
+    render("git_tuto.Rmd")
+    ```
+
+Os diretórios criados durante a compilação são sempre apagados, para que ao
+compilar novamente, tudo seja reproduzido. O projeto deve recriar tudo e
+é essa a intenção, apesar do custo. Se os diretórios não fossem
+deletados antes de uma nova compilação, iria-se receber erros de
+compilação.
+
+Esse documento usa instruções no terminal que podem ser particulares do
+Linux, como o comando `tree` e `sed`. Portando, a reprodutibilidade da
+compilação pode não acontecer em outros sistemas operacionais.
+
+## O fluxo de trabalho
+
+Esse projeto terá dois ramos persistentes:
+
+  * `devel`: que irá receber imediatamente a contribuição dos
+    membros e será submetido a teste (no caso compilação). Se bem
+    sucedido, a contribuição é movida para o ramo `master`.
+  * `master`: que recebe a versão estável do projeto.
+
+Os membros devem criar ramos de demanda para adicionarem suas
+contribuições. Por exemplo, se existe a demanda (*issue*) de acrescentar uma
+sessão sobre o uso do programa `meld` para resolver conflitos de merge,
+deve-se criar um ramo para isso, adicionar as contribuições e subir esse
+ramo para o repositório remoto. Os *issues* criados no GitLab são
+automaticamente numerados. Para nosso benefício, vamos usar o mesmo
+número ao criar os *branches* para atender as correspondentes
+demandas. Vamos usar o padrão `issue#?` em que `?` representa o número
+do *issue*.
+
+```sh
+git branch -b issue#3
+
+... trabalha, git add, git commit ...
+... trabalha, git add, git commit ...
+... trabalha, git add, git commit ...
+
+git push origin issue#3
+```
+
+Assim que der o `git push`, a próxima etapa é fazer uma requisição de
+*merge*. Isso se faz pela interface do GitLab clicando em
+[merge request][] no menu da esquerda, dentro da página do projeto, e
+depois no botão *New Merge Request*. Lá é onde se designa o responsável
+por avaliar e aplicar o *merge* e quais os *branches* envolvidos
+(doador/receptor).
+
+Existe apenas uma regra que jamais deve ser quebrada:
+
+> Nunca dê `push` para os ramos `devel` e `master`.
+
+Esses ramos se receberão conteúdo provenientes de *merge* dos ramos de
+demanda (*issue*).
+
+## Mensagens de commit
+
+É extremamente recomendado, por questões de organização e produtividade,
+que as mensagens de commit sejam apropriadas. Não use mensagens vagas ou
+óbvias do tipo *Modificações feitas*, *Arquivos incluídos*. Procure algo
+como *Incluí arquivo de estilo CSS*, *Modifica preâmbulo*, *Troca
+'require' por 'library'* ([5 dicas para melhores commits][]).
+
+Exitem formas especiais de escrever um *commit* que tenha ações do
+repositório remoto como fechar um *issue* ou fazer uma referência a
+outro *commit* ([ações nas mensagens de commit][]). As palavras
+especiais são: `close`, `closes`, `closed`, `fix`, `fixes`, `fixed`,
+`resolve`, `resolves`, `resolved`. Depois das palavras vem uma
+identificação de *issue* ou *sha1*.
+
+```sh
+git commit -m "Close #4. Bug devido ao encoding."
+```
+
+Visite para mais dicas de como escrever um *commit*:
+[como-escrever-boas-mensagens-de-commit][]
+
+## Escrita do código
+
+Recomenda-se fortemente que ao escrever o código, não se ultrapasse 72
+caracteres por linha. Isso torna o texto/código mais legível nos
+arquivos fontes. Linhas longas são difíceis de ler nos monitores atuais, 
+que possuem uma tela grande.
+
+Editores de texto (de verdade) geralmente possuem formas de auto quebrar
+linhas, auto indentar/acomodar ou sinalizar a margem direita. O Emacs
+tem [auto break lines][] e [refluxo de texto][]. Outros editores
+permitem exibir uma linha vertical para indicar o limite, como o RStudio
+(> Tools > Global Options > Code > Display > Margin column).
+
+[markdown]: http://br-mac.org/2013/09/o-que-e-markdown.html
+[rmarkdown]: http://rmarkdown.rstudio.com/
+[merge request]: https://gitlab.c3sl.ufpr.br/pet-estatistica/git-tutorial/merge_requests
+[ações nas mensagens de commit]: https://help.github.com/articles/closing-issues-via-commit-messages/
+[5 dicas para melhores commits]: https://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message
+[auto break lines]: http://emacswiki.org/emacs/LineWrap
+[refluxo de texto]: http://www.emacswiki.org/emacs/FillParagraph
+[como-escrever-boas-mensagens-de-commit]: http://blog.diovani.com/post/101092814586/como-escrever-boas-mensagens-de-commit
diff --git a/plano.md b/plano.md
index c758878..95012b8 100644
--- a/plano.md
+++ b/plano.md
@@ -29,7 +29,7 @@
       1. Habilitar comunicação
       2. Gerenciar repositórios
    3. Fluxo de trabalho
-   4. Macanísmos de colaboração
+   4. Mecanismos de colaboração
       1. Issues e merge request
       2. Fork e pull request
    5. Integração contínua
@@ -54,7 +54,7 @@
       1. Clonar, modificar e subir
       2. Resolver um bug
       3. Incorporar o remoto ao local
-      4. Resolver confito de merge
+      4. Resolver conflito de merge
       5. Voltar o projeto para um commit
       6. Deletar ramos
       7. Criar ramo de um commit passado
@@ -84,7 +84,7 @@
    + Walmes: terminar o que tem para ser feito para GitHub, adicionar
      chaves, verificar conexão, criar renomear projeto, clonar,
      modificar e subir. Renomear, deletar e transferir projeto.
-   + Gabriel: Descrever o usdo do `init`, `add`, `commit`, definir as
+   + Gabriel: Descrever o uso do `init`, `add`, `commit`, definir as
      três áreas de presença das modificações e acompanhar modificações
      com `diff`, `log`, `status` e `reflog`.
    + Ângela: Incluir as ilustrações dos modelos de workflow.
@@ -92,13 +92,13 @@
      versão preliminar da apostila correspondentes à Linux e Windows.
    + Eduardo: concluir as seções sobre uso da `git gui`, `gitk`, `gitg`
      e `gitx`.
-   + Alessandra: configurar conexão serviador via ssh, criar e
+   + Alessandra: configurar conexão servidor via ssh, criar e
      transferir as chaves públicas, criar um repositório no servidor e
      cloná-lo.
    + Alcides: concluir o dicionário de termos.
    + Daniel: concluir o conteúdo do *cheat sheet*.
 3. 2015-11-10 [week03]:
-   + Walmes: escrever para o GitLab o mesmo contúdo para presente para o
+   + Walmes: escrever para o GitLab o mesmo conteúdo para presente para o
      GitHub. Isso vai de uma breve descrição das funcionalidades, como
      criar conta e gerenciar um repositório.
    + Gabriel: **finalizar o trabalho da semana anterior**. Escrever
@@ -115,17 +115,17 @@
    + Daniel: Definir o conteúdo previsto no *cheat sheet* e concluir o
      capítulo sobre SCV. Revisar o capítulo da Ângela.
 4. 2015-11-17 [week04]:
-   + Walmes: descrever os mecanísmos de colaboração com interfaces web:
+   + Walmes: descrever os mecanismos de colaboração com interfaces web:
      issue, fork e merge request.
    + Gabriel: Acréscimos de revisão do capítulo. Revisar os apêndices do
      Alcides.
    + Ângela: Descrever o fluxo de trabalho do PET. Revisar o capítulo da
      Jhenifer.
-   + Jhenifer: Acrécimos de revisão. Revisão do capítulo da Alessandra.
+   + Jhenifer: Acréscimos de revisão. Revisão do capítulo da Alessandra.
    + Eduardo: Documentar o uso das ferramentas de merge: meld, kdiff3 e
      p4merge.
-   + Alessandra: Acréscismos e revisão. Revisar o capítulo da Ângela.
-   + Alcides: Acréscismos e revisão. Revisar o capítulo do Gabriel.
+   + Alessandra: Acréscimos e revisão. Revisar o capítulo da Ângela.
+   + Alcides: Acréscimos e revisão. Revisar o capítulo do Gabriel.
    + Daniel: **finalizar todo o trabalho da semana anterior**. Concluir
      o capítulo sobre Git com o RStudio
 5. 2015-11-24 [week05]:
@@ -184,16 +184,16 @@
    + Gabriel: Disponibilizar o capítulo 3 para o Eduardo até sexta.
    + Walmes: Juntar todos os capítulos e gerar a Apostila Git.
 8. 2015-12-15: Apostila Git concluída!
-   + Daniel: Não concluiu nenhum dos comprimissos assumidos. As
-     pendendências devem ser incorporadas na segunda fase do Projeto.
+   + Daniel: Não concluiu nenhum dos compromissos assumidos. As
+     pendências devem ser incorporadas na segunda fase do Projeto.
    + Gabriel: Enviou de forma inacabada os compromissos que assumiu;
-   + Ângela: Fez a capa. Concluiu a primera fase da apostila sem nenhuma
+   + Ângela: Fez a capa. Concluiu a primeira fase da apostila sem nenhuma
      pendência;
-   + Jhenifer: Concluiu a primera fase da apostila sem nenhuma
+   + Jhenifer: Concluiu a primeira fase da apostila sem nenhuma
      pendência;
-   + Walmes: Concluiu a primera fase da apostila sem nenhuma pendência;
+   + Walmes: Concluiu a primeira fase da apostila sem nenhuma pendência;
    + Eduardo: Concluiu com tudo em dia
-   + Alessandra: Concluiu a primera fase da apostila sem nenhuma
+   + Alessandra: Concluiu a primeira fase da apostila sem nenhuma
      pendência;
    + Alcides: Fez as modificações mas não pediu MR.
 
-- 
GitLab