Skip to content

Politica de Criação de Branchs

Histórico de Versões

Data Versão Descrição Autor
03/03 0.1 Abertura do documento com template inicial Rafael e Roberto
03/03 0.2 Adição dos tópicos 1,2 e dos subtópicos de 2 Rafael e Roberto

1. Introdução

   Esse documento tem por objetivo padronizar a criação de branchs no repósitorio do Anunbis. Dessa forma, se torna indispensável a presença da issue, funcionalidade aos quais a branch se refere.

2. Branchs Principais

2.1 Master

   Essa é a branch que contém o código mais estável do Anunbis. Tudo que o usuário consome da versão atual está aqui. As diretrizes dela são:

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

2.2 Develop

   Destinada ao desenvolvimento do projeto. Ou seja, toda novidade está nessa branch. Suas diretrizes são:

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

2.3 Document

   Destinada à criação e manutenção dos documentos do projeto, ou seja, toda alteração na gitpage, local principal dos documentos, passa por essa branch. Diretrizes:

  • Deve ser derivada da develop;
  • Deve ser mesclada a develop aṕos documento ser concluído;
  • Seu nome segue o padrão:
document/issueID-Nome_da_Funcionalidade

  Onde:

  • "document" é padrão;
  • "issueID" é o número da issue ao qual o documento se refere;

  Exemplo:

document/#88-Atualizar_Roadmap

2.4 Feature

   Destinada à criação de uma novas funcionalidades ao projeto. Diretrizes:

  • 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/issueID-Nome_da_Funcionalidade

  Onde:

  • "feature" é padrão;
  • "issueID" é o número da issue ao qual a funcionalidade se refere;

  Exemplo:

feature/#55-Criar_Feed_de_Notícias

2.5 Release

   Branch que contém um conjunto de funcionalidades que podem ser implementadas na master. Diretrizes:

  • Deve ser derivada da develop;
  • Após ser concluída deve ser mesclada na master;
  • Nenhuma nova funcionalidade pode ser inserida na master se não por meio da release;
  • Somente aceita mesclagens do tipo bugfix;
  • A cada nova release, o número do extremo esquerdo deve ser incrementado em 1;
  • O nome dessa branch deve seguir o padrão:
release/vNúmero.versão

  Onde:

  • "release" é padrão;

  Exemplo:

release/v2.5

2.6 Bugfix

   Branch destinada a resolver problemas como bugs e erros presentes na release. Diretrizes:

  • Deve ser derivada da release;
  • Deve ser mesclada a release depois de finalizada;
  • Seu nome segue o seguinte padrão:
bugfix/issueID-Nome_do_bugfix

  Onde:

  • "bugfix" é padrão;
  • "issueID" é número da issue ao qual o bugfix se relaciona;

  Exemplo:

bugfix/#89-Resolver_Feed_de_Noticias

2.7 Hotfix

   Destinada a resolver problemas urgentes na master. Diretrizes:

  • Deve ser derivada da master;
  • Dever ser mesclada a master e a develop apos ser concluida;
  • 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/vNúmero.Versão

  Onde:

  • "hotfix" é padrão;

  Exemplo:

hotfix/v2.6

3. Referências

GABRIEL, Enzo; et al. Política de Branches - Vamos Cuidar. Disponível em: https://fga-eps-mds.github.io/2020.1-VC_Usuario/#/docs/policies/branches. Acesso em: 03 mar 2021.