Histórico de Revisão
Data | Versão | Descrição | Autor |
---|---|---|---|
29/08/2020 | 0.1 | Correção na política de branch | Guilherme |
02/09/2020 | 1.0 | Criação do documento de polílica de pull requests | Gabriel Filipe |
02/09/2020 | 1.1 | Adiciona referências | Gabriel Filipe |
03/09/2020 | 1.2 | Revisão | Mateus Augusto |
07/10/2020 | 1.3 | Concerta imagens | Gabriel Filipe |
Criação de Pull Request
Considere uma situação hipotética onde estamos querendo criar um PR de uma branch chamada Sprints para a master.
Nota:
- A criação do PR deve ser feita logo após o início do trabalho em uma issue. Para isso trabalhamos com a flag de status WIP.
Para a criação de um pull request direcionado a branch master, deve-se seguir os seguintes passos:
1) Adicione a flag de status
- Titule o PR com a tag WIP (ou seja work in progress)
2) Adicione uma descrição
- Utilize o template de issue destinada ao pull request.
- Lembrando que o pull request tem a branch base a master e a compare a branch que se deseja juntar.
- Lembrando: assim que for realmente finalizado as alterações referentes ao pull request, deve-se retirar a tag WIP.
3) Adicione os reviewers
- Assinale os reviewers, ou seja, aqueles responsáveis à análise do pull request. Por exemplo, caso sua feature esteja relacionada a arquitetura do projeto, assinale o EPS que desempenha esse papel.
4) Adicione os assignees
- Assinale os colaboradores do pull request
5) Adicione as devidas labels
- Marque as labels relacionadas ao pull request. Geralmente será as mesmas assinaladas na issue referente.
6) Adicione a devida milestone
- Marque a Milestone, ou seja, a sprint ou release atual.
7) Explicite a issue relacionada ao PR
- Conecte a issue trabalhada neste pull request por meio de closing keywords.
Issue a ser linkada | Sintaxe | Examplo |
---|---|---|
Issue dentro deste repositório | KEYWORD #ISSUE-NUMBER | Closes #10 |
Conflitos
- Se um pull request causar algum tipo de conflito, deve ser resolvido primeiro pela equipe que desenvolveu o que está causando conflito, prezando pela integridade e organização do histórico de commits, e então deve ser refeito o pedido para avaliação do merge.
Política de Aprovação do Código
- Para a aprovação do código, este deve ser aprovado por ao menos um dos integrantes do time de gestão (EPS)
Referências
-
Lino. Disponível em https://github.com/BotLino/Lino
-
Como fazer bons commits no Git, Ruan Brandão. Disponível em https://ruanbrandao.com.br/2020/02/04/como-fazer-um-bom-commit/
-
Git branch naming conventions, Sanket. Disponível em https://deepsource.io/blog/git-branch-naming-conventions/