Skip to content
Snippets Groups Projects
Commit bfbcfe7b authored by Ângela Luiza Cunha Legey's avatar Ângela Luiza Cunha Legey
Browse files

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

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