Política de Branches

Para o repositório Doc

Main

Branch principal do repositório, apresenta código em sua última versão e estável para o usuário final. Por isso possui as seguintes regras:

Só existe uma main no projeto;
Commits não são permitidos diretamente nessa branch;
Mudanças nela só ocorrem por meio de pull requests das branches hotfix ou docs.

Docs

As branches são nomeadas seguindo um padrão para uma melhor organização do repositório e rastreio de commits. Por se tratar de um projeto baseado em documentos, terá apenas um tipo de nomenclatura de branch. Todas as branchs devem ser criadas a partir da main e devem estar nomeadas da seguinte maneira:

  docs/X-nome_documento

  Exemplo: 
  docs/1-guia_contribuicao

Onde:

X: o número da issue associada
nome_documento: nome do artefato construído

Caso não tenha um documento/artefato sendo construído coloque apenas o número da issue.

Hotfix

Branch destinada a resolver incidentes em produção/main. Suas regras são:

Deve ser derivada da main;
Dever ser mesclada a main após concluída;

hotfix/nome_documento

Exemplo:
hotfix/guia_contribuicao

Onde:

nome_documento: nome do artefato que está sendo corrigido.

Para os repositórios de Desenvolvimento

Main

Branch principal do MeasureSoftGram, apresenta código em sua última versão e estável para o usuário final. Por isso possui as seguintes regras:

Só existe uma main/master no projeto;
Commits não são permitidos diretamente nessa branch;
Mudanças nela só ocorrem por meio de pull requests das branches release ou hotfix.

Develop

Branch destinada ao desenvolvimento, onde as novidades partem dela. Suas regras são:

Só existe uma branch develop no projeto;
Deve ser sincronizada com todas as outras branches;
Deve ser derivada da main/master.

Feature

Branch destinada as novas funcionalidades. Suas regras são:

Deve ser derivada da develop;
Deve ser mesclado de volta a develop após a funcionalidade ser desenvolvida;
Toda nova funcionalidade tem sua própria branch, seguindo o seguite padrão de nome:

feature/X-nome_da_funcionalidade

Exemplo:
feature/2-crud_usuarios

Onde:

X: número da issue associada.
nome_da_funcionalidade: nome da funcionalidade desenvolvida.

Release

Branch com um lote de funcionalidades que posteriormente serão adicionadas a main. Suas regras são:

Deve ser derivada da develop;
Após ser concluída deve ser mesclada na main/master;
Nenhuma nova funcionalidade pode ser inserida na main/master se não por meio da release;
Somente aceita mesclagens do tipo bugfix;
O nome dessa branch deve seguir o padrão:

release/vnumero.numero.numero

Exemplo:
release/v1.0.28

Onde:

numero: versionamento.

Bugfix

Branch responsável por corrigir bugs encontrados na release. Suas regras são:

Deve ser derivada da release;
Deve ser mesclada a release após concluída;
Seu nome segue o seguinte padrão.

bugfix/X-nome_do_bugfix

Exemplo:
bugfix/32-corrige_erro_listagem_usuarios

Onde:

X: número issue associada.
nome_do_bugfix: Bug que foi corrigido.

Hotfix

Branch destinada a resolver incidentes em produção/main. Suas regras são:

Deve ser derivada da main/master;
Dever ser mesclada a main/master após concluída;
A cada novo hotfix, a versão do produto deve ser modificado, incrementando uma unidade ao número extremo direito. O nome segue o seguinte padrão:

hotfix/vnumero.numero.numero

Exemplo:
hotfix/v2.4.3

Onde:

numero: versionamento.

Referências

[1] DRIESSEN, Vincent. A successful Git branching model. [S. l.], 5 jan. 2010. Disponível em: https://nvie.com/posts/a-successful-git-branching-model/. Acesso em: 15 outubro. 2022.

[2] GITFLOW Workflow. [S. l.], 201-. Disponível em: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow. Acesso em: 15 outubro. 2022.

[3] Guia de contribuição fga-eps-mds/2022-2-MeasureSoftGram-Doc. Disponivel em: https://fga-eps-mds.github.io/2022-2-MeasureSoftGram-Doc/politicas/branches/. Acesso em: 15 outubro. 2023.

Histórico de Versão

Versão	Data	Descrição	Autor	Revisor
1.0	19/10/2023	Versão inicial do documento	Ariel Vieira Lima Serafim Lameque Fernandes