Skip to content

Política de Branches

Versionamento

Versão Data Modificação Autor
1.0 30/04/2023 Criação do documento Carlos Eduardo de S. Fiuza
1.1 30/04/2023 Adição dos tópicos Carlos Eduardo de S. Fiuza e Jonathan Oliveira
1.1 05/05/2023 Revisão do documento Paulo Batista, Davi Matheus e Luis Marques

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: 10 nov. 2022.

[2] GITFLOW Workflow. [S. l.], 201-. Disponível em: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow. Acesso em: 10 nov. 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: 30 abril. 2023.