Skip to content

Home

Jump to bottom
Felipe Duarte Luna edited this page Mar 12, 2024 · 1 revision

Contribuindo com o Painel Administrativo.

Conteúdo

Introdução

Este guia tem por objetivo definir as regras para criação de Branches, Pull Requests e Commits no projeto Painel Administrativo. Para seguir o guia é fundamental o conhecimento da ferramenta Git.

Regras para criação da Branch

Antes de criar uma nova branch deve-se assegurar de estar na branch master do projeto. Caso já esteja na main rode o comando:

git pull

Se não retornar nenhum erro ela estará atualizada e é hora de criar a branch no projeto Painel Administrativo. Para isso rode o comando:

git checkout -b <COMPONENTE>/<ISSUE>

Onde o <COMPONENTE> deve conter o nome do componente e não o projeto onde ele se encontra. E a <ISSUE> é o número da ocorrência a qual se refere a alteração. Exemplos:

Caso a ISSUE seja gerada no Jira:

git checkout -b po-button/DSERTSS2-13334

Caso a ISSUE seja gerada no GitHub:

git checkout -b po-button/235

Caso não exista uma ISSUE definida, crie a branch com o nome do desenvolvedor ou o nome do time e não esqueça de detalhar o que está sendo sugerido na descrição da Pull Request. Para isso rode o comando:

git checkout -b <COMPONENT>/<DEV|TEAM>

Exemplo:

git checkout -b po-button/fulano

Regras para criação de Commits

Seguindo a convenção para mensagens de commit utilizadas em projetos de desenvolvimento de software. Essa convenção visa padronizar o formato das mensagens de commit para facilitar a leitura, o rastreamento de alterações e a geração de informações úteis a partir do histórico de commits.

As mensagens de commit seguem um formato específico, geralmente composto por três partes principais:

Tipo: Indica o propósito do commit, como "feat" (para uma nova funcionalidade), "fix" (para correções de bugs), "docs" (para alterações na documentação), "chore" (para tarefas de manutenção), entre outros.

Escopo (opcional): Descreve o escopo da alteração, como um módulo específico do projeto ou um componente.

Descrição: Uma breve descrição da alteração realizada no commit.

fix(auth): Corrigir erro de autenticação quando a senha é inválida

Lista dos principais Tipos de commits utilizados:

  • feat: Utilizado para adicionar uma nova funcionalidade ao projeto (Adição de telas, novos botões, relatórios). Exemplo: feat: Adicionar opção de tema escuro
  • fix: Utilizado para correção de Bugs/Manutenção. Exemplo: fix: Corrigir erro de digitação no formulário de login
  • docs: Utilizado para alterações na Documentação do projeto. Exemplo: docs: Atualizar README com instruções de instalação
  • style: Utilizado para alterações que não afetam o código em si, mas sim o estilo/formato do código. Exemplo: style: Remover espaços em branco no final do arquivo
  • refactor: Utilizado para refatorações de código, ou seja, alterações que melhoram a estrutura ou organização do código sem alterar sua funcionalidade. Exemplo: refactor: Extrair função duplicada em um utilitário
  • test: Utilizado para adicionar, alterar ou corrigir testes automatizados. Exemplo: test: Adicionar teste para validação de e-mail
  • chore: Utilizado para tarefas de manutenção, como atualização de dependências, configurações de build, etc. Exemplo: chore: Atualizar pacotes do npm para a versão mais recente
  • perf: Utilizado para melhorias de desempenho. Exemplo: perf: Otimizar algoritmo de busca
  • revert: Utilizado para reverter um commit anterior. Exemplo: revert: Reverter alterações no arquivo de configuração

Regras para Pull Request

Os titulos das Pull requests do Painel Administrativo devem seguir o padrão abaixo:

<< Codigo da ISSUE / Requisito >> - << Titulo da Historia / Requisito >>

Versionamento da Release

Mapear e documentar a versão semântica (Semantic Versioning ou SemVer) para o seu projeto no GitHub é uma boa prática para manter um controle claro e consistente das mudanças em seu software. O SemVer é um sistema de versionamento que utiliza números de versão de forma significativa, indicando os tipos de mudanças que foram feitas em um projeto. A versão é dividida em três partes: Major, Minor e Patch. Aqui está um guia passo a passo para mapear e documentar o SemVer em seu projeto do GitHub:

Escolhendo uma versão inicial:

Comece escolhendo um número de versão inicial para o seu projeto, como 1.0.0, que normalmente é a primeira versão pública estável.

Definindo os tipos de mudanças:

O Versão Semântica classifica as mudanças em três tipos: Major, Minor e Patch.

  • Major (X.0.0): Quando você faz mudanças incompatíveis na API ou realiza grandes refatorações.

  • Minor (0.X.0): Quando você adiciona funcionalidades de maneira compatível com versões anteriores.

  • Patch (0.0.X): Para correções de bugs e alterações que não afetam a funcionalidade existente.

Etiquetas de versão no Git:

No GitHub, utilize as "etiquetas" (tags) do Git para marcar as versões. Crie uma tag para cada versão seguindo o padrão SemVer. Você pode criar uma tag diretamente na linha de comando com o comando git tag, ou usar a interface gráfica do GitHub.

Changelog:

Mantenha um arquivo "CHANGELOG.md" no seu repositório para documentar as mudanças em cada versão. Liste as principais alterações para cada tipo de versão (Major, Minor, Patch) e forneça uma breve descrição do que foi modificado.

Clone this wiki locally