From f532dd6c74a9c4d5c4caa1efdcec426509d33754 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jo=C3=A3o=20Henrique=20Egewarth?= Date: Fri, 16 Mar 2018 03:24:26 -0300 Subject: [PATCH] #5 Adicionando politica de pull requests e commits MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: João Henrique Egewarth --- CONTRIBUTING.md | 56 ++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 51 insertions(+), 5 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index d6b9096b..edb880d9 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -20,23 +20,69 @@ As branchs de desenvolvimento de features serão criadas a partir da branch deve Em casos de issues de features de produção, o nome da branch deve ser “X_nome_da_issue”. X representa o código de rastreio da issue. - +Para criar a branch, vá para a branch `development`: ``` git checkout development +``` +Depois é só criar a branch e pronto!, está pronto para produzir. +``` git checkout -b X_nome_da_issue ``` ### Política de Commits -[[docs/img/commit-dupla.png|Commit individual]] +Todos os commits devem ser feitos usando o comando `-s` para indicar sua assinatura no commit. +``` +git commit -s +``` +A issue em questão deve ser citada no commit, para isso, basta adicionar `#`+numero_da_issue ao commit. + +``` +git commit -sm"#5 Fazendo guia de contribuição" +``` + +[[docs/img/commit-individual.png|Commit individual]] + +Para commits em dupla deve ser usado o comando `-s` igualmente, e deve ser adicionado a assinatura da sua dupla. + +``` +git commit -s +``` +Comentário do commit: +``` +#5 Fazendo guia de contribuição + +Signed-off-by: João Henrique Egewarth +Signed-off-by: Eliseu Egewarth +``` [[docs/img/commit-dupla.png|Commit dupla]] -### Política de Merges +### Política de Merges e Pull Requests +#### Pull Requests +Os pull requests externos devem ser feitos apenas para a branch `development` seguindo as regras e os passos do tópico "Merges para development". No conteúdo do pull request deve haver uma descrição clara do que foi feito. + +[IMAGEM PULL REQUEST EXEMPLO] + +Para a equipe interna, os pull requests seram realizados em duas situações, para `development` e para `master` seguindo as regras e passos de merge para ambas branchs. + +##### Labels + +| Label name | Description +| --- | --- | +| `work-in-progress` | Pull requests que ainda estão em andamento, mais modificações estão por vir. | +| `needs-review` | Pull requests que precisam de revisão de código. | +| `under-review` | Pull requests em revisão de código. | +| `requires-changes` | Pull requests que precisam de modificações e devem ser revisadas de novo. | +| `needs-testing` | Pull requests que precisam ser testados. | + + #### Merges para development -Os merges para development deverão ser feitos quando a funcionalidade ou refatoração estiverem de acordo com os seguintes aspectos: +Os merges para `development` deverão ser feitos quando a funcionalidade ou refatoração estiverem de acordo com os seguintes aspectos: · Funcionalidade ou refatoração concluída · Build do Travis passando +· Testes feitos +· Funcionalidade revisada por algum outro membro Para fazer um merge para development os passos a serem seguidos são: · Atualizar a branch “development” local usando o comando “git pull --rebase origin development” @@ -47,6 +93,6 @@ Para fazer um merge para development os passos a serem seguidos são: #### Merges para master -Os merges para master deveram ser feitos apenas após o término da sprint, quando todas as funcionalidades estiverem entregues. O merge deve ser feito a partir da development e apenas quando atingir os seguintes critérios: +Os merges para master deveram ser feitos apenas após o término da sprint, quando todas as funcionalidades estiverem entregues. O merge deve ser feito a partir da development e apenas quando atingir os seguintes critérios: · Build Travis passando · Sprint dada como concluída