Padronização do Git

Fluxo de Branches

Foi definido que o fluxo de branches utilizado para o desenvolvimento e manutenções de produtos de software será uma adaptação do Git Flow.

O fluxo padrão do Git Flow é o apresentado na figura a seguir.

Com base no fluxo padrão do Git Flow teremos as seguintes adaptações:

Não serão utilizadas branches release. O uso de branches release será avaliado posteriormente.
Não será utilizada a branch develop em alguns sistemas onde existe um fluxo intenso de demandas urgentes, como por exemplo o eTCE-GO. Neste caso todas as branches serão criadas a partir da branch main. Posteriormente avaliaremos o uso da branch develop neste cenário.

Nomenclatura das branches:

main: branch principal e referência para implantação do produto de software em produção.
develop: branch de desenvolvimento e referência para implantação do produto de software nos ambientes de teste e homologação.
feature/nome-da-nova-funcionalidade-ou-melhoria: branch criada como espelho da develop e utilizada pelo desenvolvedor durante a codificação da nova funcionalidade ou melhoria de uma funcionalidade existente.
bugfix/identificação-do-bug: branch criada como espelho da develop e utilizada pelo desenvolvedor durante a codificação da correção de bugs.
hotfix/identificação-do-bug: branch criada como espelho da main e utilizada pelo desenvolvedor durante a codificação da correção de bugs que precisam ser corrigidos urgentemente.
tag: marcação criada na branch main para identificar uma nova versão implantada em produção. Exemplo: 1.0.0

Versionamento

Foi definido que será aplicado o versionamento semântico para todo produto de software desenvolvido e mantido pelo tribunal.

O padrão para a identificação de versão será como definido a seguir:

MAJOR.MINOR.PATCH
- MAJOR: incrementado para grandes mudanças, mudanças incompatíveis com versões anteriores ou uma referência para um conjunto de mudanças.
- MINOR: incrementado para adicionar funcionalidades.
- PATCH: incrementado para correções de bugs.
Exemplos:
- 1.0.0: primeira versão estável.
- 1.1.0: versão com novas funcionalidades compatíveis com a versão 1.0.0.
- 1.1.1: versão com correções de bugs compatíveis com a versão 1.1.0.
- 2.0.0: segunda versão com mudanças incompatíveis com a versão 1.0.0.

Changelog

O changelog é um registro, em um documento padronizado, de todas as mudanças realizadas em um produto de software ao longo do tempo. Este serve como histórico de inclusão de novas funcionalidades, correções de bugs e demais manutenções realizadas no software.

Foi definido que deve ser criado um changelog para cada produto de software desenvolvido e mantido pelo tribunal. A cada novo incremento de versão o changelog deve ser atualizado.

O changelog será inicialmente armazenado no Git Source na raiz do projeto do produto de software. O nome do arquivo será changelog.md e será preenchido com o padrão Markdown.

Os seguintes dados devem estar contidos no changelog:

Versão: número da versão, por exemplo, 2.1.3.
Data: data da implantação da nova versão em produção.
Descrição das Mudanças: uma lista detalhada das mudanças, organizadas pelas categorias a seguir.
- Novas Funcionalidades: novas funcionalidades ou recursos incluídos.
- Correções: correções de bugs, problemas e defeitos.
- Alterações: mudanças em funcionalidades existentes.
- Melhorias: melhorias de usabilidade, desempenho, otimizações, etc.
- Remoções: funcionalidades ou recursos removidos.
- Segurança: correções de vulnerabilidades de segurança.

Exemplo de preenchimento: