Política de Branches

Com o intuito de possuir uma melhor dinâmica de mudanças de código, é importante que tenhamos uma boa política de branches. Este documento servirá de base para criação de branches e como serão organizadas, estas baseadas no git flow que é um modelo de organização de branches.

Aqui será descrito como funcionará as branches do projeto.

• Branch master - Esta será a branch que contém o código em nível de produção, será o código mais consolidado existente na aplicação. Todo o código novo produzido eventualmente é juntado com a branch master, em algum momento do desenvolvimento;

• Branch develop - Develop é a branch que logo após releases deverá ser identica à master, porém, quando as features são terminadas, elas são juntadas nesta branch, testadas e somente depois as atualizações da develop passam pelo processo de juntar as novas atualizações com a branch master;

• Branches feature - Essas são as branches na qual são desenvolvidos novos recursos ao projeto, elas serão criadas com o nome começando feature/ (exemplo: feature/new-layout) e a partir da branch develop, e, ao final, são juntadas com a branch develop;

• Branches hotfix - São branches no qual são realizadas correções de bugs críticos encontrados em ambiente de produção, e que por isso são criadas a partir da branch master, e são juntadas diretamente com a branch master e com a branch develop. Por convenção, essas branches tem o nome começando com hotfix/ e terminando com o próximo sub-número de versão (exemplo: hotfix/2.31.1);

• Branches release - São branches com um nível de confiança maior do que a branch develop, e que se encontram em nível de preparação para ser juntada com a branch master e com a branch develop, nessas branches, bugs encontrados durante os testes das features que vão para produção podem ser corrigidos mais tranquilamente, antes de irem efetivamente para produção. Por convenção, essas branches tem o nome começando com release/ e terminando com o número da próxima versão do software, exemplo (release/2.32.0);