VERSIONAMENTO DE CÓDIGO: ENTENDENDO GITFLOW E TRUNK BASED DEVELOPMENT

[@CanalDebug]

Segue lá no instagram.com/debug.uchoa

[@henriquenas]

curti bastante o vídeo !! quem me dera ter uma dicção assim e sua camiseta de wallpapper do whatsapp é bem legal

[@ziul911]

Excelente vídeo! As ilustrações do funcionamento das diferentes branches nos dois frameworks ficaram ótimas

[@rael2100]

Achei f*da, simples e objetivo, sem muita firula kkk show de bola Lucas parabéns.

[@CanalDebug]

Valeu Jorge

[@cajuudoido]

Meu maior problema com esses modelos de branch é que onde trabalho tenho ambientes separados para desenvolvimento, homologação e produção. Ai sempre surge funcionalidades que vão pra homologação, mas são recusadas, ai depois querem subir só aquelas aprovadas para produção. Nesse esquema eu teria que juntar a partir das feature branches ou fazer um cherry pick para criar um release?

[@TheArrowster]

Pois é cara, isso não funciona, tenho o mesmo pensamento, do jeito que é proposto se vc precisar subir suas alteraçoes vai precisar obrigatoriamente, pegar as funcionalidades que foram concluidas primeiro, e pra tirar da uma dor de cabeça do caramba pq ja foram commitadas antes. Esses modelos são uma furada.

[@ronssm]

@@TheArrowster como resolver entao?

[@TheArrowster]

@@ronssm cada empresa tem seu jeito de fazer isso, mas uma maneira simples seria cada dev trabalhar em sua branch e apenas quando for autorizado pela equipe de homologação/testes o mesmo fazer o commit na master, ai essa develop nesse cenário seria descartada.

[@ronssm]

@@TheArrowster mas desse jeito vc teria que ter uma "fila"pra subir em homologacao e testar... isso parece inviavel em grande escala... o metodo com cherry pick consegue manter o ambiente de homologacao com tudo que precisa ser testado e caso alguma coisa não seja aprovada, as demais poderiam seguir, fazendo o cherry pick.

[@CasenriqueLacerda]

Muitas coisas podem ser feitas, mas para o seu problema especifico eu sugiro pesquisar sobre feature flags. (Bander Vc isola o codigo desenvolvido e nao testado atravez de feature flags para que ele seja testado(sendo executado apenas fora de ambiente de produçao inicialmente) , e quando ele for testado e aprovado, vc remove a flag para que apenas aquela funcionalidade va para produção Uma feature flag pode ser um if em um codigo tipo: if(!isProd) {seu codigo aqui} else {codigo anterior, caso se aplique} No modelo de trunk based, sao feitas automatizações de teste e utiliza-se feature flags para controlar as condiçoes em que determinada funcionalidade iria ser executada Com feature flags e disciplina da equipe (a branch principal NUNCA pode quebrar) vc isola o codigo instavel do codigo que irá para produçao Parte da questao do trunk based development é reduzir a burocracia para subir algo para produçao, trabalhar com integraçao continua e entrega continua Vc pode usar ferramentas de gestao de feature flags se nescessario

[@drayanelopes]

Parabéns pelo vídeo! Surgiu uma dúvida: no git flow eu preciso ter um produto? ou seja, preciso de algo já criado? Não entendi mt bem essa parte. Poderia me explicar, por gentileza?

[@brunajellinek1686]

Como sempre muito bom!!!

[@CanalDebug]

Muito obrigado 😁

[@Victor-de8jq]

Atualmente to usando o gitflow, mas em um tutorial vi falar que o Desenvolvimento Baseado em Troncos é melhor, então vim pesquisar.

[@juliakatharineteixeirasilv6589]

Muito bom.

[@efraimraizer]

Mto bom

[@efraimraizer]

Massa

[@deveduoliveira]

Muito show, esclareceu bastante coisa cara, estou iniciando num projeto e comentaram sobre merge request, seria algo parecido com PR também??

[@CanalDebug]

É exatamente a mesma coisa, o nome é diferente pq um é no github e o outro no bitbucket ou gitlab

[@LucianoBargmann]

Uchoa, 1a vez no teu canal, curti tua didática, mas precisa corrigir o grafico (ou pelo menos adiciona uma nota) aos ~4:28 - Cada seta saindo dos feature branchs gera uma bolinha verde diferente. Abração

[@CasenriqueLacerda]

Po, acho que se vc ta criando feature branch entao vc ta ainda fazendo uma versao de feature based development, e nao trunk based development Eu sei que tem divergencias em alguns lugares sobre trunk based development, mas voce nem falou sobre feature flags O que eu compreendi pelas minhas pesquisas é que o trunk based é uma resposta contra branchs de longa duraçao, entao sugeriria vc falar que para ser trunk based a feature branch deveria ser bem curta, desenvolvimento incremental, com pequenas modificaçoes, para poder reduzir o risco de conflito de merge(mesclagem) O git flow é um tipo de feature based development sugestao de leitura : martinfowler - branching patterns sobre trunk based development : trunkbaseddevelopment ponto com Inclusive o ponto do trunk based é ter o minimo de branchs possiveis , nessa sua explicaçao do trunk based vc ja mostrou que em um projeto pode ter varias feature branchs, o que perde o sentido de chamar de trunk based

[@gustavohiratak]

A main seria a branch copia da master ou ela é a master?

[@CanalDebug]

Ela é a master.... É que master/slave remete a escravidão e a comunidade está parando de usar essa nomenclatura e usando main no lugar 😉

[@gustavohiratak]

@@CanalDebug ahhh entendi :)) Vlww

[@therealdecross]

@@CanalDebug Cara, não problematiza bobagem. Se você faz um git init qual é o nome do branch que ele cria? Master! Não complica.