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;

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:

  doc/X-nome_documento

  Exemplo: 
  doc/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 2024.2-T01-CRMProInjeca, 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: 18 novembro. 2024.

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

Histórico de Versão¶