Política de Branches e Contribuição
Histórico de Revisões
Versão
Descrição
Autor
1.0
Políticas
Thiago Ribeiro
1. Introdução
Este documento tem como objetivo padronizar e explicitar as políticas de contribuição a serem seguidas pela equipe durante o desenvolvimento do projeto.
2. Políticas
2.1 Política de Contribuição na Wiki
Com o intuito de manter a rastreabilidade e controle das alterações feitas na Wiki do projeto, o usuário que for adicionar ou modificar algum conteúdo deverá incluir uma pequena mensagem, no campo adequado, explicando a alteração feita. Esta mensagem deve estar em inglês com o verbo no gerúndio e o ponto final ao fim da frase.
Exemplo:
“Adding policy guide.”
2.2 Política de Commits
Os commits devem ser atômicos, representando uma funcionalidade ou parte dela. A mensagem deve descrever o que foi produzido, de forma sucinta. Além disso, o commit deve ser iniciado com uma hash acompanhado do número, que representa a issue a qual esse commit pertence. Assim como a mensagem para contribuir na wiki, o commit deverá ser em inglês atendendo o seguinte padrão.issue - Texto com a primeira letra da frase maiúscula, verbo no gerúndio, terminando com o ponto final. > .
Exemplo:
“#2 - Adding user model.”
"#17 - Creating user tests."
2.3 Política de Branches
Haverá apenas um repositório com uma branch principal (master) e uma branch auxiliar de desenvolvimento (devel). Será necessária a criação de branches auxiliares para o desenvolvimento de cada história de usuário ou história técnica, essas serão ramificações da devel. Após o término da funcionalidade, os desenvolvedores responsáveis deverão mesclar o conteúdo da branch auxiliar na qual a funcionalidade foi desenvolvida com a branch auxiliar de desenvolvimento (devel). Essa tarefa deve ser realizada com o comando merge. A funcionalidade deverá ser integrada a master através do pull request, onde o qualidade do código será analisada.
As branches auxiliares deverão ser criadas a partir do padrão a seguir: USUser story>- ou TSTechnical story>-. Onde US representa as histórias de usuário e TS histórias técnicas.
Exemplos:
“US01-Login”
"US07-FilterCompany"
2.4 Política de Aprovação do Código
O código será aprovado caso seja funcional e siga todas as especificações da folha de estilo com a aplicação das técnicas de programação, tais como: identação, presença de loggings, comentários, ou seja, o uso de programação defensiva. Além disso o código deverá conter uma cobertura de testes mínima determinada pelo time, assim como, satisfazer todos os requisitos das ferramentas de análise de código. O Scrum Master da sprint em questão deverá revisar o código presente em cada pull request. Caso não obedeça às regras e não seja explicado o não uso de uma das especificações estabelecidas acima o Scrum Master deverá recusar o pull request a branch master e voltar a branch devel para a última versão estável.
Last updated