Fala galera,
tudo beleza?
Organização é algo muito importante para desenvolvimento de aplicações, principalmente nos repositorios de código. Uma falta de organização adequada pode resultar em perda de código, merges erroneos, problemas de segurança, versões incorretas colocadas em produção e etc.
Uma forma que eu gosto muito de organização de branchs é o GitFlow e é dele que vamos falar hoje. Bora?
Calma! A Imagem acima pode ate assustar um pouco, mas eu garanto que é mais simples do que é!
O Gitflow, desenvolvido por Vincent Driessen, oferece uma estrutura clara para colaboração e integração contínua, permitindo um desenvolvimento mais organizado e escalável. Ele pode ser aplicado a qualquer serviço que hospede repositorios Git , porem GitHub oferece recursos e ferramentas que facilitam a implementação e o gerenciamento desse fluxo.
Então utilizando o Github como exemplo vamos entender as etapas do Fluxo :
1. Repositório "master/main" e "develop":
Quando criamos um projeto no GitHub, temos um repositório vazio.
O branch "main" é criada como a versão mais estável e entregável do software. Esta branch contém apenas o código que está em produção e é considerado estável e pronto para ser implantado. Ela não deve ser modificado diretamente. Em vez disso, as alterações são trazidas de outros branches, como a branch "release" e a branch "hotfix" que veremos mais para frente.
Devemos criar uma branch "develop" que seria o ambiente de desenvolvimento contínuo. Esta Branch contém todo o código em desenvolvimento, incluindo novos recursos, correções de bugs e melhorias. É a partir da branch "develop" que novos branches de features, releases são criados. Podemos dizer que a Develop é a branch candidata a ir para produção.
2. Branches de feature:
Essas branches são usados para adicionar novos recursos ao projeto. Elas são criados a partir da branch "develop" e são nomeados de forma descritiva, como "feature/nome-da-feature". As branches de feature são desenvolvidos independentemente e, quando concluídos, são mesclados de volta para o branch "develop".
Por exemplo :
Um desenvolvedor (ou responsavel pelo repositório) cria um branch de feature chamado "feature/adicionar-tarefas" no GitHub a partir do branch "develop", em seguida ele ou a equipe trabalha na branch fazendo várias alterações para implementar o recurso. são feitos diversos commits e pushs das alterações para o branch no GitHub.
Quando o desenvolvimento está concluído, o desenvolvedor abre um pull request (PR) no GitHub para mesclar a branch de feature na branch "develop".
Outros membros da equipe (ou algum responsavel) revisam o código, fazem comentários e, finalmente, o PR é aprovado e mesclado no GitHub.
3. Branches de hotfix:
Essas branches são usados para corrigir bugs críticos encontrados no código em produção. Elas são criadas a partir do branch "main" e, quando concluídas, são mesclados tanto na branch "main" quanto na branch "develop". Isso garante que a correção seja refletida tanto na versão atual em produção quanto na próxima versão em desenvolvimento.
Por exemplo :
Alguem encontra um erro/bug crítico no código em produção, uma branch de hotfix chamado "hotfix/bug-critico" é criada no GitHub a partir da branch "main".
Após a correção do bug é e os commits feitos no GitHub ,um PR é aberto para mesclar a branch de hotfix no branch "main".
O PR é revisado, aprovado e mesclado no GitHub, garantindo que a correção seja refletida tanto na versão atual em produção quanto na próxima versão em desenvolvimento.
4. Branches de release:
Quando o código na branch "develop" está pronto para ser colocado em produção, uma branch de release é criado a partir dele.
A branch de release é usado para realizar atividades finais de teste, correção de bugs e preparação para o lançamento. Qualquer correção de bug necessária é feita diretamente na branch de release. Quando o branch de release está pronto, ela é mesclada tanto no branch "main" quanto no branch "develop", marcando assim uma nova versão do software.
Por exemplo :
Quando o código na branch "develop" está pronto para ser liberado, uma branch de release chamado "release/v1.0" é criada no GitHub a partir da branch "develop".
Após a conclusão da branch de release, um PR é aberto no GitHub para mesclar o branch de release no branch "main".
O PR é revisado, aprovado e mesclado no GitHub, marcando assim uma nova versão do software.
De forma simples estas são as Etapas. É possivel adapta-las para o uso do dia a dia de forma que atenda a necessidade da sua equipe, assim como nomenclaturas utilizadas nos nomes de releases,hotfix e features.
O que eu gosto da utilização desse padrão com o Github é que ele fornece uma interface intuitiva e ferramentas poderosas para facilitar o uso do Gitflow. temos recursos como pull requests, revisões de código, rastreamento de problemas e integração contínua para ajudar as equipes a colaborar e gerenciar o desenvolvimento de software de forma eficiente.
Utilizar o Gitflow com o GitHub, podemos ter um fluxo de trabalho estruturado, facilitando a coordenação e a colaboração entre os membros da equipe. A combinação dessas duas ferramentas permite um controle preciso sobre as diferentes etapas do ciclo de vida do código, promovendo um desenvolvimento mais organizado, estável e confiável.
Espero ter ajudado!
Aquele abraço!
Top comments (0)