Revisa sessão de boas práticas de colaboração

cp_07.Rmd

@@ -57,7 +57,7 @@ projeto.
 colaboradores externos colaborem e precisam de algumas orientações básicas
 sobre como colaborar. Criando um arquivo `CONTRIBUTING.md` com este guia,
 ele será automaticamente colocado em uma aba na página inicial do projeto.
-- (**Opcional**) um *changelog* para que sejam registradas as modificações 
+- (**Opcional**): um *changelog* para que sejam registradas as modificações 
 realizadas entre uma versão e outra (principalmente para softwares). 
 Criando esse arquivo com estas informações, ele aparecerá automaticamente 
 em uma aba na página inicial do projeto. 
@@ -65,11 +65,13 @@ em uma aba na página inicial do projeto.
 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.
-Por causa dessa importância, uma mensagem bem escrita é a melhor forma 
-de se comunicar a alteração para os demais membros do grupo e para você 
-mesmo. Essas mensagens também aparecerão no git log do projeto,
-por isso é essencial que sejam bem escritas, de forma clara e sigam um 
-padrão.
+Os commits agilizam o processo de revisão do projeto, e poderá ajudar
+futuros mantenedores do projeto a desvendar o motivo de algum acréscimo
+ou modificação no código. Por causa dessas importâncias, uma mensagem bem 
+escrita é a melhor forma de se comunicar a alteração para os demais membros 
+do grupo e para você mesmo. Essas mensagens também 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:
@@ -120,25 +122,30 @@ de uma mensagem de commit mais longa. Espaço é valioso quando se temos
 no máximo 50 ou 72 caracteres.
 
 5.**Use o modo imperativo**: no título de commits longos ou em mensagens 
-de commits únicas. O modo imperativo significa "falar ou escrever como 
-se estivesse dando uma ordem ou uma instrução". Seja direto e objetivo, 
-e escreva no presente. Exemplos de mensagens no impertativo:
-
+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:
+```sh
 - Adiciona versão final
 
+- Altera parágrafo da introdução
+
 - Remove funções precipitadas
+```
 
 Algumas mensagens no modo **não** imperativo são:
-
+```sh
 - Corrigindo o erro
 
 - Mudando a função 
 
 - Mais correções para mais funções
+```
+
 
 6.**Limite o corpo da mensagem em 72 caracteres**: ao escrever uma mensagem 
-de commit mais longa, após o título devemos manter o corpo da mensagem 
-com no máximo 72 carateres.
+de commit mais longa, devemos manter o corpo da mensagem com no máximo 
+72 carateres.
 
 
 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 
@@ -146,7 +153,7 @@ deixar de fora como você fez as modificações, pois o código alterado já
 deverá ser auto-explicativo. 
 
 
-#### Esqueleto do tópico
+### Esqueleto do tópico
 
 - Repositórios: níveis de acesso, adicionar colaboradores, configuração 
 inicial do repositório
@@ -159,7 +166,8 @@ inicial do repositório
 - *Descrever os quatro principais tipos de workflow (Centralized workflow,
 Feature branch workflow, gitflow workflow e Forking workflow)*
 
-- *Materiais de apoio* <a href="http://git.leg.ufpr.br/leg/gitlab-rautu/blob/master/CONTRIBUTING.md">
+- *Materiais de apoio* 
+<a href="http://git.leg.ufpr.br/leg/gitlab-rautu/blob/master/CONTRIBUTING.md">
 gitlab-rautu do Fernando Mayer</a> ; 
 <a href="https://prezi.com/_lm8kozmii8n/git-workflow/"> apresentação do 
 Diego G. Pasqualin</a>

cp_07.md

@@ -52,7 +52,7 @@ projeto.
 colaboradores externos colaborem e precisam de algumas orientações básicas
 sobre como colaborar. Criando um arquivo `CONTRIBUTING.md` com este guia,
 ele será automaticamente colocado em uma aba na página inicial do projeto.
-- (**Opcional**) um *changelog* para que sejam registradas as modificações 
+- (**Opcional**): um *changelog* para que sejam registradas as modificações 
 realizadas entre uma versão e outra (principalmente para softwares). 
 Criando esse arquivo com estas informações, ele aparecerá automaticamente 
 em uma aba na página inicial do projeto. 
@@ -60,11 +60,13 @@ em uma aba na página inicial do projeto.
 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.
-Por causa dessa importância, uma mensagem bem escrita é a melhor forma 
-de se comunicar a alteração para os demais membros do grupo e para você 
-mesmo. Essas mensagens também aparecerão no git log do projeto,
-por isso é essencial que sejam bem escritas, de forma clara e sigam um 
-padrão.
+Os commits agilizam o processo de revisão do projeto, e poderá ajudar
+futuros mantenedores do projeto a desvendar o motivo de algum acréscimo
+ou modificação no código. Por causa dessas importâncias, uma mensagem bem 
+escrita é a melhor forma de se comunicar a alteração para os demais membros 
+do grupo e para você mesmo. Essas mensagens também 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:
@@ -115,25 +117,30 @@ de uma mensagem de commit mais longa. Espaço é valioso quando se temos
 no máximo 50 ou 72 caracteres.
 
 5.**Use o modo imperativo**: no título de commits longos ou em mensagens 
-de commits únicas. O modo imperativo significa "falar ou escrever como 
-se estivesse dando uma ordem ou uma instrução". Seja direto e objetivo, 
-e escreva no presente. Exemplos de mensagens no impertativo:
-
+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:
+```sh
 - Adiciona versão final
 
+- Altera parágrafo da introdução
+
 - Remove funções precipitadas
+```
 
 Algumas mensagens no modo **não** imperativo são:
-
+```sh
 - Corrigindo o erro
 
 - Mudando a função 
 
 - Mais correções para mais funções
+```
+
 
 6.**Limite o corpo da mensagem em 72 caracteres**: ao escrever uma mensagem 
-de commit mais longa, após o título devemos manter o corpo da mensagem 
-com no máximo 72 carateres.
+de commit mais longa, devemos manter o corpo da mensagem com no máximo 
+72 carateres.
 
 
 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 
@@ -141,7 +148,7 @@ deixar de fora como você fez as modificações, pois o código alterado já
 deverá ser auto-explicativo. 
 
 
-#### Esqueleto do tópico
+### Esqueleto do tópico
 
 - Repositórios: níveis de acesso, adicionar colaboradores, configuração 
 inicial do repositório
@@ -154,7 +161,8 @@ inicial do repositório
 - *Descrever os quatro principais tipos de workflow (Centralized workflow,
 Feature branch workflow, gitflow workflow e Forking workflow)*
 
-- *Materiais de apoio* <a href="http://git.leg.ufpr.br/leg/gitlab-rautu/blob/master/CONTRIBUTING.md">
+- *Materiais de apoio* 
+<a href="http://git.leg.ufpr.br/leg/gitlab-rautu/blob/master/CONTRIBUTING.md">
 gitlab-rautu do Fernando Mayer</a> ; 
 <a href="https://prezi.com/_lm8kozmii8n/git-workflow/"> apresentação do 
 Diego G. Pasqualin</a>