Ir para o conteúdo

Política de Commits

Este projeto utiliza o padrão Conventional Commits para assegurar que as mensagens de commit sejam claras, consistentes e automatizáveis. Seguir essas diretrizes facilita a criação de changelogs, automatiza o versionamento semântico e melhora a compreensão do histórico do projeto.

Formato da Mensagem

Cada mensagem de commit deve ser estruturada da seguinte forma:

<tipo>: <descrição resumida>

<corpo opcional>

Tipos de Commit

Os seguintes tipos de commit são permitidos:

  • feat: Introduz uma nova funcionalidade.
  • fix: Corrige um bug.
  • docs: Alterações apenas na documentação.
  • style: Alterações que não afetam o significado do código (formatação, ponto e vírgula, etc.).
  • refactor: Refatoração do código (sem correções de bugs ou novas funcionalidades).
  • perf: Melhora o desempenho.
  • test: Adiciona ou modifica testes.
  • chore: Alterações na configuração da build, scripts auxiliares, etc. (sem alteração no código de produção).
  • revert: Reverte um commit anterior.

Descrição Resumida

A descrição resumida deve ser concisa e começar com uma letra maiúscula. Deve completar a frase:

Este commit irá....

Exemplo: corrigir visualização do artefato de EAP

Corpo

O corpo da mensagem é opcional e deve oferecer detalhes adicionais sobre a modificação, incluindo a motivação e a implementação. Separe o corpo da descrição resumida com uma linha em branco.

Co-autores

Este projeto suporta o uso de Co-authored-by para atribuir crédito a múltiplos autores em um único commit. A informação de co-autoria deve ser adicionada no rodapé do commit, após o corpo da mensagem (se houver) e antes de outros trailers, como BREAKING CHANGE: ou referências a issues.

Formato:

Co-authored-by: Nome do Co-autor <emailcoautor@example.com>

Você pode adicionar múltiplas linhas Co-authored-by para incluir vários co-autores.

Exemplo:

docs: adicionar o diagrama de pacotes no artefato de arquitetura

Co-authored-by: Nome do Co-autor <emailcoautor@example.com>
Co-authored-by: Outro Co-autor <outroemail@example.com>

Recomendações:

  • Utilize Co-authored-by sempre que houver colaboração significativa em um commit.

Política de Branches

Esta política define a estrutura de branches do projeto e como elas devem ser utilizadas para organizar o desenvolvimento e garantir a estabilidade do código.

Tipos de Branches

O projeto utiliza os seguintes tipos de branches:

  • main: A branch principal e estável, representando o estado pronto para produção do projeto. Push direto nesta branch é proibido. Todas as alterações devem ser incorporadas através de merge requests.

  • artefato/{nome-do-artefato} ou modulo/{nome-do-modulo}: Branches dedicadas ao desenvolvimento de um artefato ou módulo específico. O nome da branch deve ser descritivo e refletir a parte do sistema sendo modificada.

  • Exemplos: 
`artefato/diagrama-de-classes`; 
`modulo/autenticacao`;
`artefato/documentacao-usuario`.


  • doc/{nome-da-alteracao-na-documentacao}: Branches específicas para alterações na documentação.
  • Exemplos: 
`doc/tutorial-instalacao`;
`doc/atualizacao-readme`.

Atualização do mkdocs.yml

Se a alteração que você fez, consistiu na criação de um novo arquivo de documento dentro do projeto, que precise ser adicionado para acesso ao git Pages, você deve incluílo no arquivo mkdocs.yml. Presente na raíz desse projeto.

Na parte nav do arquivo mkdocs, insira, no tópico do seu arquivo, o nome dele e o seu caminho, na seguinte estrutura:

 - <Nome do arquivo>: <caminho do arquivo dentro de docs/>

Exemplo:

Inserindo o arquivo de documento "Manual de Montagem" dentro do mkdocs.

nav:
  - Sobre o Projeto: 
    - Home: home.md
  - Geral:
      - Visão: geral/visaogeral.md
      - Arquitetura: geral/arquitetura.md
      # outros diversos arquivos
  - Eletrônica e Energia:
      - Arquitetura de Eletrônica: eletronica_energia/arquitetura_eletronica.md
      - Arquitetura de Energia: eletronica_energia/arquitetura_energia.md
      # outros diversos arquivos
  - Estruturas:
      - Arqiutetura: estruturas/arquitetura_subs_estruturas.md
      - EAP: estruturas/EAP_estruturas.md
      # inserção da seguinte linha:
      - Manual de Montagem: estruturas/Manual_montagem_estruturas.md 
  - Software:
      - Arquitetura: software/arquitetura.md
      - Backlog: software/backlog_produto.md
      # outros diversos arquivos

Fluxo de Trabalho

  1. Criação de Branches: Todas as novas funcionalidades, correções de bugs, alterações na documentação ou infraestrutura devem ser feitas em branches separadas, criadas a partir da main.

  2. Nomenclatura: Siga as convenções de nomenclatura descritas acima para cada tipo de branch.

  3. Commits: Utilize o padrão Conventional Commits em todas as mensagens de commit.

  4. Merge Requests: Antes de fazer o merge uma branch na main, crie um merge request. Isso permite revisão de código e garante a qualidade do projeto.

  5. Merge na main: Após a revisão e aprovação do merge request a branch proposta deve ser mesclada na main.

  6. Exclusão de Branches: Após o merge, as branches de recursos, documentação e infraestrutura devem ser excluídas para manter o repositório organizado.

  7. Obs: Se possível o ideal é sempre manter a sua branch, ou repositório local, atualizada utilizando os comandos git fetch e git pull

Bibliografia

  1. Conventional Commits
  2. Semantic Versioning
  3. Hugo Melo. Estudo de arquitetura de agenda na matéria com Milene Serrano. Disponível em: GitPages
Versão Data Descrição Responsável
1.0 29/11/2024 Versão inicial do artefato. Yago Passos
1.1 29/11/2024 Seção de atualização de mkdocs Yago Passos