Bom, e antes a gente tem aqui? A gente tem uma branch principal, que é a main. Essa branch é a branch onde todos os desenvolvedores vão fazer as interações. Sempre que a gente tiver que fazer alguma alteração, a gente vai utilizar aqui brands do tipo feature. Só que a princípio essas brands são para curta duração. Então a gente inicia elas e rapidamente a gente já faz um merge dessas alterações para a nossa branch main e o desenvolvimento continua acontecendo dentro da nossa branch tronco aqui a gente também tem as branchs do tipo release então sempre que a gente queira rodar uma bateria de testes, rodar todos aqueles testes integrados, testes unitários, qualidade, enfim, a gente vai fazer a promoção desse código para uma branch release e a gente vai evoluir ali até a gente conseguir ter uma versão estável e gerar uma tag ali a partir dessa versão estável. Esse desenvolvimento ele continua acontecendo, beleza, consegui fazer o merge ali da minha segunda funcionalidade e agora eu tenho o meu código aqui já atualizado rodando aqui na minha main, quero rodar uma bateria nova para gerar uma versão nova da minha aplicação, novamente eu volto a fazer uma branch do tipo release faço todos os testes está funcionando beleza, está bacana sempre que posso continuar o desenvolvimento dentro dessa mesma branch e gerar ali uma funcionalidade nova e tem um detalhe importante como que eu faço para gerar algum hotfix a partir desse modelo de desenvolvimento? Das duas, uma, né? Ou você vai escolher um determinado commit que foi feito para você conseguir empurrar essas alterações né então você vai você não vai fazer alterações direto na sua branch main pra você não afetar o seu ambiente produtivo mas você consegue basicamente escolher como se fosse algum comitê específico que esteja aqui, fazer um cherry pick, certo? E aí você geraria uma nova versão, que poderia ser aí uma 2.1, por exemplo, né? Com a sua correção, tá bom? E esse modelo de desenvolvimento, ele tem algumas vantagens, então a gente pode colocar a questão da simplicidade, por ele ter uma abordagem muito mais simples e direta, você acaba fazendo todo o desenvolvimento em uma única branch, então acaba tornando um pouco mais simples esse desenvolvimento. um pouco mais simples esse desenvolvimento a gente também está falando de entregas contínuas então sempre que você uma vez que você está desenvolvendo numa branch do tipo feature a gente tende a ter mais merges para main justamente pela facilidade então a gente está continuamente testando o nosso software e a questão da agilidade a praticidade e a facilidade com que tem esse modelo de desenvolvimento faz com que a gente acabe tendo uma agilidade maior porque você vai desenvolver e rapidamente você consegue já empurrar essa funcionalidade para dentro da sua branch main ali. Todavia, a gente também tem algumas desvantagens. Então, a gente pode ter um problema de conflitos frequentes, principalmente pensando em projetos com uma complexidade um pouco maior, onde tenham vários desenvolvedores trabalhando direto nessa branch nessa branch main e a gente também tem aí a questão dos riscos de regressão então imagina que eu estou desenvolvendo ali uma funcionalidade você está desenvolvendo uma funcionalidade totalmente diferente a menos que a gente já suba essas funcionalidade, você está desenvolvendo uma funcionalidade totalmente diferente, a menos que a gente já suba essas funcionalidades ali no modelo de Toggle, por default desabilitado, a gente pode ter algum tipo de problema de concorrência, de quem sobe primeiro, esse código, e também alguma coisa, alguma funcionalidade que já esteja funcionando, ela vir a parar de funcionar, justamente porque a gente tem uma interação muito maior dentro desse código. Mas isso a gente acaba conseguindo dar uma certa driblada, tendo uma cobertura de testes adequada. tendo uma cobertura de testes adequada. E, utilizando aqui o segundo modelo, que seria o GitFlow, a gente tem uma abordagem bem diferente. Então, a gente está falando de três brands principais, Develop, Release e a Main. Cada uma dessas branches elas são meio que pinadas em cada um dos nossos ambientes, né? Então, Develop no ambiente de desenvolvimento, Release em QA e a Main para a produção e como que funciona tá a gente tem a nossa branch develop sempre que eu quero fazer o desenvolvimento de uma funcionalidade nova eu gero a partir da develop uma branch específica de feature faço todo o desenvolvimento e levo o merge pra minha pra minha branch develop, tá? Em paralelo, a minha branch develop também tem aqui algumas alterações, né? Uma vez que eu tenha um ambiente ok, eu consigo fazer a promoção dela pra pra release, onde a gente vai ter aqui um release candidate nesse caso tá é beleza faz toda a evolução está funcionando bem agora consequentemente também acaba encadeando aqui alguns alguns outros comitês tá beleza tem a versão funcionando bem consigo fazer a promoção para o meu ambiente de prod e gerar aqui minha primeira versão estável e esse fluxo ele é contínuo toda vez que a gente precisar gerar novas funcionalidades então a gente gera uma bridge do tipo feature, faz todo o desenvolvimento faz o merge para develop da develop a gente faz o merge para QA e da QA a gente faz o merge para release e main. E como que funciona nesse caso quando a gente quer fazer um, a gente tem algum bug, a gente precisa fazer um hotfix a gente tem basicamente um fluxo intermediário como se fosse aqui mais ou menos certo é que a gente consegue gerar uma branch do tipo hotfix e essa branch ela vai ser baseada em alguma versão de produção tá então você gera essa branch a partir da man beleza coda esse hotfix e uma vez que você tenha isso pronto a partir desse cara a gente vai disparar um pr pra develop ea gente vai disparar um pr pra nem tá é pra develop pra gente justamente conseguir depois equalizar o nosso código, fazer a promoção para a QA também, e para a main para a gente conseguir de fato fazer a implantação desse bug fix. E quais são as vantagens dessa abordagem? Acaba sendo muito mais organizado, porque a gente tem ali as brands com um escopo bem delimitado, certo? Acaba fazendo também uma certa mitigação de conflito, porque a gente tem cada uma das brands isoladas, cada um trabalha com um escopo bem definido. E a questão de estabilidade. A gente tem aqui os testes em desenvolvimento, tem os testes em QA, então quando a gente sobe para a produção, a gente tem a garantia de que aquilo que está indo para a produção é aquilo que de fato foi desenvolvido, é aquilo que de fato foi testado, então acaba tendo essa vantagem. E a gente também tem algumas desvantagens nessa abordagem, certo? A gente pode estar falando aí de complexidade, uma vez que agora a gente tem muito mais etapas para a gente promover esse código para produção e ver aquela funcionalidade implementada já rodando para os usuários finais. E a gente também está falando de overhead de gerenciamento, porque a gente tem uma sequência de PRs aqui para todo lado. Muitas vezes pode acabar ficando centralizado ali em algum tech lead, alguma coisa nesse sentido. Então, desenvolvi, fiz a promoção na develop, quero levar para a QA, vou ter que ter um code review. Então, a gente pode ter algum tipo de overhead nesse sentido também. E o pace de desenvolvimento, pensando em uma funcionalidade nova ou num projeto que esteja com um prazo muito mais apertado, é uma abordagem que vai acabar levando um pouco mais de tempo para a gente conseguir ter todas as funcionalidades, ter uma versão produtiva funcionando ali.