From 89c7f0942878856f5a0e2426a9debe0d02f66775 Mon Sep 17 00:00:00 2001
From: Walmes Zeviani <walmes@ufpr.br>
Date: Fri, 25 Sep 2015 18:59:36 -0300
Subject: [PATCH] =?UTF-8?q?Modifica=20sess=C3=A3o=20'fluxo=20de=20trabalho?=
 =?UTF-8?q?'.?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 CONTRIBUTING.md | 35 ++++++++++++++++++++++++++---------
 1 file changed, 26 insertions(+), 9 deletions(-)

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index e10d43e..4004003 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -61,25 +61,38 @@ Esse projeto terá dois ramos persistentes:
   * `master`: é o da versão estável do projeto.
 
 Os membros devem criar ramos de demanda para adicionarem suas
-contribuições. Por se existe a demanda 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.
+contribuições. Por 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 usaMeld
+git branch -b issue#3
 
 ... trabalha, git add, git commit ...
 ... trabalha, git add, git commit ...
 ... trabalha, git add, git commit ...
 
-git push origin usaMeld
+git push origin issue#3
 ```
 
 Assim que der o `git push`, a próxima etapa é fazer uma requisição de
-merge que se dá pela interface do GitLab clicando em [merge request][]
-no menu da esquerda, dentro da página do projeto. Lá é inde se designa o
-responsável por avaliar e fazer o merge.
+*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 o *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
 
@@ -100,6 +113,9 @@ identificação de *issue* ou *sha1*.
 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
@@ -120,3 +136,4 @@ permitem exibir uma linha vertical para indicar o limite, como o RStudio
 [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
-- 
GitLab