Guia de Contribuição

Este é o guia de contribuição para o projeto Sentinela, produzido pelos alunos de 2024.2. Este guia cobre os repositórios Usuários, Benefícios, Financeiro e Front-End. O objetivo deste documento é estabelecer um padrão claro e consistente para todas as contribuições feitas ao projeto, garantindo qualidade, organização e facilidade de colaboração entre os participantes.

As contribuições ao projeto devem ser iniciadas a partir das issues disponíveis no repositório de documentação, que podem ser acessadas por meio deste link. Antes de começar a trabalhar em uma issue, é importante entender e seguir as diretrizes descritas neste guia.

Para gerenciar o desenvolvimento do projeto, utilizamos o Git Flow. Este modelo organiza as branches de forma a separar o desenvolvimento contínuo do código e as versões estáveis. A branch principal, master, contém sempre as versões mais estáveis do código e deve ser utilizada apenas para o lançamento de novas versões do sistema.

As branches criadas para desenvolvimento devem seguir um padrão específico. O nome de cada branch deve conter o número da issue associada, seguido por uma descrição curta e significativa do problema ou funcionalidade a ser implementada. Por exemplo, uma branch para a issue número 42 sobre a implementação de login social poderia ser nomeada como 42-login-social. Seguir esse padrão ajuda na identificação rápida do propósito de cada branch e melhora a organização do repositório.

No que diz respeito aos commits, é fundamental seguir um formato padronizado para manter a consistência e a clareza do histórico de alterações. Cada commit deve começar com um label que descreve o tipo de alteração realizada, seguindo as labels dos Conventional Commits . As principais labels são feat para novas funcionalidades, fix para correções de bugs, docs para alterações na documentação, e test para adição ou modificação de testes. Após o label, deve ser indicado o número da issue relacionada entre colchetes, seguido por uma mensagem curta e clara que descreva a alteração. Por exemplo: [feat:42] - Adiciona funcionalidade de login social. Esse padrão facilita a rastreabilidade das mudanças e a compreensão do trabalho realizado.

Os Pull Requests (PRs) são uma etapa crucial no fluxo de trabalho e devem ser submetidos seguindo o template oficial do repositório. No início do PR, deve ser indicada a issue associada usando a seguinte estrutura: **Issue:** closes #X, onde #X é o número da issue correspondente. Em seguida, o PR deve conter uma seção chamada "Descrição", onde o autor explica detalhadamente as mudanças realizadas e como elas se relacionam com a issue associada. Essa descrição é essencial para que os revisores compreendam o escopo do trabalho e avaliem a qualidade e a relevância das alterações.

Para garantir a aceitação de um Pull Request, é necessário cumprir alguns requisitos. O PR deve ter um título descritivo e sucinto, um responsável atribuído como Assignee, um revisor designado como Reviewer, e rótulos (Labels) que identifiquem o tipo de alteração ou o estágio do PR. Além disso, a descrição do PR deve estar completa, seguindo o template descrito acima, e deve incluir a referência clara à issue associada. Somente PRs que tenham passado pelo processo de Integração Contínua (CI) e tenham sido revisados minuciosamente pelo responsável designado serão aceitos. Esse processo garante que o código enviado ao repositório esteja alinhado com os padrões de qualidade do projeto e não introduza falhas ou inconsistências.

Histórico de Versões

Versão	Nome da Versão	Data	Responsável	Descrição/Alterações
1.0	Criação do documento	07/12/2024	Clara Marcelino	Criação do documento