Skip to content

Política de Contribuição

Versionamento

Versão Data Modificação Autor
1.0 29/01/2022 Criação do documento João Pedro Moura
1.1 20/02/2022 Adição da política de pull request João Pedro Moura

Políticas de Branch para o repositório Doc

As branches serão nomeadas seguindo um padrão para a melhor organização do projeto. Por se tratar de um projeto baseado em documentos, terá apenas um tipo de nomenclatura de branch. Todas as branchs devem ser criadas a partir da master e devem estar nomeadas da seguinte maneira:

X-Nome_Documento 
Exemplo: 4-Política_de_Contribuição

Sendo X o número da issue atribuída seguido pelo nome do documento, como destacado anteriormente. Em ocasiões em que não se está trabalhando com nenhum documento em específico, então deve-se colocar o nome da issue correspondente.

Políticas de Branch para os repositórios Dev

Ao contrário do repositório Doc, as branchs dos repositórios Dev (Frontend e Backend) seguem o padrão GitFlow e devem ser derivadas da develop. A seguir existe uma explicação mais detalhada para cada branch:

Branch Master

A branch master deverá conter todo código que se encontra em produção, ou seja, essa branch será a responsável por receber os commits derivados de cada release através de um merge.

  • Só existe uma branch Master.
  • Commits não são permitidos diretamente nessa branch.
  • Os commits devem ocorrer por pull requests das branchs Develop a cada release e Bugfix

Branch Develop

Similar a branch master, ela armazena o código principal do projeto, entretando para o ambiente de homologação. Ou seja, todo o código que se encontra nessa branch é o mais atualizado, podendo conter bugs e funcionalidades ainda em desenvolvimento.

  • Só existe uma branch Develop.
  • Commits não são permitidos diretamente nessa branch.
  • Os commits devem ocorrer por pull requests das branchs individuais Feauture e Hotfix

Branchs Feauture

Branchs individuais em que cada desenvolvedor deverá estar trabalhando. Focada na adição de novas funcionalidades que estaram presentes na branch develop.

  • Existem diversas branchs Feauture.
  • Commits diretos devem ser feitos nessas branchs.
  • Derivadas da Develop.
  • Devem sempre ser devolvidas para a Develop.
  • Formato: feature/numeroIssue-nome_feature

Branchs Hotfix

Branchs individuais para que os desenvolveldores resolvam bugs e erros urgentes presentes na branch Develop

  • Existem diversas branchs Hotfix.
  • Commits diretos devem ser feitos nessas branchs.
  • Derivadas da Develop.
  • Não necessitam de reviews
  • Formato: hotfix/numeroIssue-nome_feature

Branchs Bugfix

Branchs individuais para que os desenvolveldores resolvam bugs e erros urgentes presentes na branch Master

  • Raramente devem existir branchs Bugfix.
  • Commits diretos devem ser feitos nessas branchs.
  • Derivadas da Master.
  • Formato: bugfix/numeroIssue-nome_bug

Políticas de Commits

Os commits devem ser feitos de maneira clara e objetiva respeitando os padrões comentados a seguir:

  • Devem estar escritos em português.
  • Os verbos devem estar no gerúndio.
  • Devem apresentar o número base da issue.

  Portanto a formatação do commit será: #4 Corrigindo documento de planejamento

Vale a pena lembrar que é possível utilizar o seguinte Hook já configurado para esse repositório, que acrescentará automaticamente o número da Branch em seu commit:

#!/bin/sh
BRANCH=$(git branch | grep "*" | sed 's/* \([0-9]*\)-.*/#\1/')
TEXT=$(cat "$1" | sed '/^#.*/d')

if [ -z "$BRANCH" ]
then
    echo "Branch não esta no formato NUMERO-TITULO_ISSUE."
fi

if [ -n "$TEXT" ]
then
    echo "$BRANCH" "$TEXT" > $1
else
    echo "Commit sem mensagem."
    exit 1
fi

E por fim, nas ocasiões em que o commit for realizado por duas ou mais pessoas, deve ser acrescentado à mensagem do commit o seguinte texto: 

#4 Corrigindo documento de planejamento


Co-authored-by: Fábio Silva <fabiosilva@gmail.com>

Política de Pull Requests

Para a realização de pull requests, a equipe definiu a utilização da poĺítica de squash e merge, metodologia essa que junta todos os commits em um único após o merge. Dessa forma, o histórico fica mais limpo e organizado, sendo ainda possível visualizar os commits mais atômicos através dos comentários disponíveis nos commits de merge.