Branchs
Conceitos
O time pode trabalhar bem e produzir código de qualidade, ainda assim, os branches e commits podem ser uma bagunça generalizada se não existir um padrão definido que toda a equipe deve seguir.
Criar (ou adaptar) um padrão para os commits e branches não é trabalhoso e se feito no começo do projeto terá zero relutância da equipe, pois todos irão decidir juntos as normas seguidas, para organizar iremos usar a ideia de Git Flow, sendo alterada para nossa realidade.
Para os commits, além dos benefícios de legibilidade, padronizar as mensagens também permite gerar um changelog de mudanças entre versões de forma mais fácil, isso porque cada commit está categorizado.
Já temos definido que teremos dois branchs que serão os principais que são eles:
Main -> Branch principal que tem o código da release em produção. Neste branch somente o coordenador do projeto poderá fazer pull request para ele e liberá-lo.
Devel ou Dev ou Developer -> Branch principal do desenvolvimento, ele receberá todos os pull request logo após testes e será verificado e depois disto o coordenador de devel poderá fazer pull request para o main e liberar release.
Assim passaremos a ter um branch de nome devel/principal -> Usando a / o git consegue criar como se fosse uma estrutura de pastas para nós. Assim o devel/principal será o branch que irá receber os pull request após finalização dos testes. Ou seja nosso branch devel estará com a release que irá para staging e posteriormente para produção.
Branches
Nomes de branches são compostos de 3 partes:
1 — type ou categoria do branch. Os types podem ser os seguintes:
devel: A branch devel é o único meio de comunicação direta com a branch master. Ele não terá nomenclatura específica pois ele será o branch ligado diretamente ao main
doc: apenas mudanças de documentação. momenclatura: doc/<o que faz o branch em si>_<codigo da tarefa>;
feature: Branchs para desenvolver funcionalidades e sao geradas a partir do develop. Ao final do ciclo de vida mesclam(fazem merge) de volta para o developr. Convenção de nomenclatura: feature/<oque o branch faz em si>_<código da tarefa> ;
hotfix: Seguem o mesmo padrão das branchs de feature, e essas branchs geralmente são criadas para correções de bugs de uma release, que não podem esperar por uma próxima release. As hotfix são criadas diretamente na master. Convenção de nomenclatura: hotfix/<o que o branch faz em si>_<codigo da tarefa>;
release: Quando a branch devel estiver com funcionalidades suficientes para uma entrega, é criada uma branch de entrega (release branch). Com isso, é dado início ao próximo ciclo de entrega, ou seja, nenhuma nova funcionalidade pode ser incluída a partir deste momento, nesta release. Quando estivermos prontos para realizar a entrega/release é mesclada com os branches main e devel
2 — o que o branch faz em si.
3 — Código da tarefa . Ex.: issue_123 ou task_123.
Exemplos de alguns nomes de branches que podem existir em nossa aplicação:
feature/cadastro_veiculos_task_123
hotfix/busca_checklists_task_232
doc/corrige_doc_cadastro_pessoa_task_256
release/testar_release_1304
Last updated