Eu, como Cuidador, desejo [...]
+Nessa tarefa, o cuidador deve [...]
+## Tarefas
+| Data | +Versão | +Descrição | +Autor | +
|---|---|---|---|
| 12/08/2024 | +1.0 | +Criação do documento | +Gustavo Abrantes | +
| 23/08/2024 | +2.0 | +Atualização do documento | +Gabriel Monteiro | +
Ao criar issues, atente-se às seguintes questões:
+Padronizar evita confusões e facilita a leitura e a procura por artefatos do projeto. Isso também se aplica à nomenclatura de branches. Por padrão, a nomenclatura de branches deve obedecer ao seguinte formato:
+<type>/<branch-name>
+O parâmetro type sinaliza o principal tipo de modificação realizada. Por padrão, utilizamos as seguintes palavras-chave:
+| Type | +Significado | +
|---|---|
| feat | +Novas funcionalidades para o usuário | +
| fix | +Correções de bugs para o usuário | +
| docs | +Modificações na documentação | +
| style | +Formatação, sem alterações no código de produção | +
| refactor | +Refatoração de código de produção | +
| test | +Adição e refatoração de testes (sem alterar código de produção) | +
| chore | +Atualizações genéricas sem alterações de código de produção | +
O parâmetro branch-name descreve de forma textual a atividade realizada dentro da branch. Por padrão, o nome da branch é escrito em inglês, substituindo os espaços por hífen ("_"). Por exemplo: Create new tests for user se torna create-new-tests-for-user.
++Atente-se para a criação de um nome coerente para sua branch, a fim de evitar confusões e incoerências.
+
Uma branch para adição de novos testes para um user:
+test/create-new-tests-for-user
+Uma branch para correção de um bug na criação de user:
+fix/remove-bug-from-user-creation
+A partir do repositório desejado:
+git fetch
+git checkout <branch-principal>
+git reset --hard <branch-principal>
+git checkout -b <type>/<branch-name>
+A política de commits deste projeto é baseada no Conventional Commits v1.0.0.
+O Conventional Commits define um conjunto de regras simples para que as mensagens de commit sejam consistentes no histórico de um repositório. Utilizar uma convenção como essa facilita a leitura do histórico, a identificação das mudanças realizadas por um commit e facilita a adoção de ferramentas de automação para gerar changelogs ou release notes.
+Por padrão, as mensagens de commits devem seguir o seguinte formato:
+<type>: <subject>
+Assim como para as branches, type descreve o tipo de modificação contemplada pelo commit. Por padrão, utilizamos as seguintes palavras-chave:
+| Type | +Significado | +
|---|---|
| feat | +Novas funcionalidades para o usuário | +
| fix | +Correções de bugs para o usuário | +
| docs | +Modificações na documentação | +
| style | +Formatação, sem alterações no código de produção | +
| refactor | +Refatoração de código de produção | +
| test | +Adição e refatoração de testes (sem alterar código de produção) | +
| chore | +Atualizações genéricas sem alterações de código de produção | +
O parâmetro subject representa a mensagem que descreve o commit, escrita em inglês. Uma boa prática é sempre escrever subjects descritivos, isto é, sempre se preocupando em deixar bem claros os conceitos de what (o que foi feito) e why (por que foi feito).
+Para clarificar as recomendações aqui mencionadas, confira estes exemplos:
++++
Modifies user model
+Ao avaliar esta mensagem de commit, o conceito what é superficial, pois não descreve especificamente o que foi alterado no modelo de usuário. O conceito why sequer existe.+
Modifies user's model name field to make it shorter
+Ao avaliar esta mensagem de commit, quem quer que a leia entenderá o motivo e do que se trata a alteração feita. Tal clareza permite poupar esforço e tempo para entender do que o commit se trata.
O Pull Request (PR) é a maneira de contribuir para projetos de grupo ou de código aberto (open source).
+Por exemplo, um usuário copia um repositório e faz alterações nesse repositório. Agora, ele pode fazer um Pull Request para o repositório original, mas cabe ao mantenedor aceitá-lo ou recusá-lo. É como dizer: "Você poderia aceitar minhas alterações, por favor?"
+git remote
+
Depois de identificar o nome do repositório remoto, podemos enviar/fazer um push dessas alterações para o GitHub:
+git push origin <nome_da_branch>
+Agora, navegue até o repositório no GitHub do projeto, e você verá um botão dizendo Compare & pull request. Clique nele.
+
Antes de clicar em Create pull request, adicione uma descrição com todos os campos a seguir:
+| Campo | +Descrição | +
|---|---|
| Nomear PR | +[#NUMERO_ISSUE] Nome do PR |
+
| Descrição | +Insira uma descrição geral do que foi alterado neste PR | +
| US | +Closes #NUMERO_US |
+
| Issue | +Closes #NUMERO_ISSUE |
+
| Principais Implementações | +Se for código, descreva alterações relevantes | +
Atenção! Ao fazer um pull request atente-se para:
+[#0] Removendo espaços vazios
+
+## Descrição
+
+- Removendo espaços vazios para evitar erros de compilação.
+
+## Issues
+
+- Closes #1
+
+## Principais Implementações
+
+- Ajustes no código para melhor performance.
+Durante a revisão, alguns pontos de atenção são importantes:
+As User Stories (US) são uma forma ágil de capturar os requisitos de uma funcionalidade sob a perspectiva do usuário final. Elas descrevem a necessidade do usuário de forma simples e direta, permitindo que o time de desenvolvimento compreenda o objetivo final da funcionalidade.
+Cada US deve seguir a estrutura básica:
+Como <persona>, eu quero <necessidade>, para que <benefício>.
+Exemplo:
+Como usuário autenticado, eu quero poder redefinir minha senha, para que eu possa acessar minha conta caso eu esqueça a senha atual.
+Ao criar uma US, atente-se aos seguintes pontos:
+**US01 - Redefinir Senha**
+
+Como usuário autenticado, eu quero poder redefinir minha senha, para que eu possa acessar minha conta caso eu esqueça a senha atual.
+
+**Critérios de Aceitação:**
+- O usuário deve poder solicitar a redefinição de senha informando o e-mail cadastrado.
+- Um e-mail com um link para redefinição deve ser enviado para o usuário.
+- O link deve ser válido por 24 horas.
+- O usuário deve poder definir uma nova senha após clicar no link.
+- A nova senha deve atender aos critérios de segurança definidos (mínimo de 8 caracteres, incluindo letras maiúsculas, minúsculas e números).
+
+**Estimate:** 5 pontos
+Assim como as Issues, as US também devem ter uma estimativa de pontuação com base na complexidade e no esforço necessário para a implementação. A pontuação será decidida em conjunto pelo time, utilizando ferramentas como o Planning Poker no ZenHub.
+Ao concluir a implementação de uma US, crie um Pull Request (PR) seguindo as orientações descritas na seção de Pull Requests deste guia. Certifique-se de:
+Durante a revisão de uma US, preste atenção aos seguintes aspectos:
+Manter a consistência de estilo de código ajuda na legibilidade e manutenção do projeto. Alguns pontos a serem considerados incluem:
+Gerenciando seus branches com o Git Flow
+ +