Politica de Criação de Branches

Histórico de Versões

Data	Versão	Descrição	Autor
10/11/2022	0.1	Abertura do documento	Rafael
10/11/2022	1.0	Adição de introdução e do fluxo de trabalho	Rafael
10/11/2022	1.1	Adição do tópico de branches e referências	Rafael
12/11/2022	1.2	Revisão do documento	Nilvan
12/11/2022	1.3	Retiradas da tag "< a>", que modificavam cor dos tópicos	Nilvan
12/11/2022	1.3	Correção do tópico de hotfix	Rafael

1. Introdução

Esse documento tem por objetivo padronizar a criação de branches nos repositório do MeasureSoftGram. Dessa forma, orientando a criação das ramificações do Git.

2. Fluxo de trabalho

O fluxo de trabalho utilizado é o Gitflow Workflow [1]. Este é um modelo alternativo que traz uma ideia abstrata do fluxo de trabalho Git, orientando os tipos de ramificações e como fazer o merge. Basicamente, são criadas as ramificações de recurso ou funcionalidade, o que possibilita retardar o merge com a ramificação do tronco principal até as necessidades definidas no escopo para lançamento de uma versão [2]. Este fluxo de trabalho auxilia um software baseado em lançamento de versões, além de oferecer a possibilidade de consertar erros identificados em produção através de hotfixes. As ramificações são explicadas abaixo.

3. Tipos de Branches

3.1 Main ou Master

Essa é a branch que contém o código mais estável do MeasureSoftGram, ou seja, o tronco principal. Tudo que o usuário consome da versão em produção se encontra nela. As diretrizes dela são:

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.
Em caso de repositório de documentação, aceita pull requests da branch document

3.3 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 branches;
Deve ser derivada da main/master.

3.3 Document

Destinada à criação e manutenção dos documentos do projeto, ou seja, toda alteração no repositório de Doc do MeasureSoftGram, local principal dos documentos, passa por essa branch. Algumas regras diferem para esse tipo de branch, devido a própria natureza do repositório de documentação, o que implica:

Deve ser derivada da main/master;
Deve ser mesclada a main/master 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

3.4 Feature

Destinada à criação de uma nova 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

3.5 Release

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

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/vNúmero.Número.Número

Onde:

"release" é padrão;

Exemplo:

release/v1.0.0

3.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 após concluída;
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

3.7 Hotfix

Destinada a resolver problemas urgentes na main/master. Diretrizes:

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

Em caso de repositório de desenvolvimento de código:

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.Número.Número

Em caso de repositório de documentação:

O nome segue o seguinte padrão:

hotfix/motivo

Onde:

"hotfix" é padrão;

Exemplo:

hotfix/v1.0.1

ou:

hotfix/guia_contribuicao

4. 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.