@@lucas_badico de boas! Eu curti sua explicação, não tinha visto ainda uma visão assim tão aprofundada. Eu tou pra mandar um comentário na thread principal sobre o assunto, mas ainda tou "preparando minha tese" hahah
@@marcuspaulo1984 desculpa maninho, é que foram 4 meses bem turbulentos. Fechei a minha empresa, encerrando com clientes e funcionarios, garantindo q todo mundo estivesse bem... Logo logo vou voltar aos temas que deixei pra tras. Tbm to devendo continuar mostrando o obsidian, entre outras coisas... Acredite, não são vazias minhas criticas. E perdao pela demora.
Eu utilizo um processo bem parecido que fiz baseado no GitFlow, como na empresa só existe eu de dev, até o momento vem me atendendo tranquilamente. Utilizo duas branchs Master e Develop, mas procuro sempre deixar as duas exatamente iguais, e vou fazendo as features em cima da develop.
Estuda o rebase mano, e as tag do git. Ajudam muito. No próximo vídeo do tema, vou mostrar o flow aqui da minha empresa. Atende times pequenos, times solos e times grandes.
A regra é clara, equipe boa joga tudo na main, todo mundo podendo fazer push, e o cd sem qa. Deu ruim, reset --hard, push --force. E o banco de dados? Ah, isso aí é detalhe besta
Gitflow estava minha lista pra ler sobre, nem vou mais haha A propósito, cheguei tem pouco tempo. Estou gostando dos vídeos. Se fizer sobre os outros pontos relacionados ao git, vou assistir hehe
Opa, vou trazer com certeza os outros pontos. Tenho 2 videos na lista: Git BASICO, pra quem ta começando e tbm pro pessoal que ta precisando de backup no obsidian, onde falarei sobre: - criar conta github - instalar git - clonar repo/iniciar repo - criar commit - abrir PR.mergear Processos Baseados em GIt - aonde eu falarei sobre usar ou nao merges - pq usar rebases - importancia de commits atomicos - importancia do git graph - Gihub actions e por ai vai - cherry pick
Até hoje só trabalhei com algum tipo de adaptação de Gitflow. Basicamente cada empresa tem o seu, e normalmente está relacionado ao fluxo de trabalho e também CI/CD.
Dev há vários anos aqui. Não uso mais Git Flow não pela premissa de que ele sempre foi ruim, mas sim porque a dinâmica, ferramentas e novas visões de processos mudaram e/ou evoluíram ao lado de novas ferramentas e metodologias. À época em que Git Flow foi criado ele era ÚTIL, sim, havia algum processo formal conhecido (mesmo se, por ventura, considerarmos ruim) - a forma de ver e entregar software era diferente. Então o fato do autor do Git Flow não mais o recomendar é pelo fato que a dinâmica e cenário mudou e temos "coisas" que não tínhamos na época. Ainda assim, alguns pontos do vídeo são válidos. Dica: cuidado com as generalizações, ainda mais na nossa área onde muita coisa depende da situação.
Muito boa a visão. Tenho trabalhado com git flow atualmente no projeto que estou alocado (talvez por estar na Holanda hahaha), mas sinceramente, não vejo tantos problemas assim. O que eu acho interessante sobre todos os tipo de processo Git é que, até então, em 15 anos de carreira, trabalhando para empresas multi-bilionárias, não vi ninguém utilizar os processos de Git para algum tipo de gerenciamento. Na verdade é sempre um pouco bagunçado (claro, uns mais que os outros) O que quero dizer com isso é: é um puta preciosismo para pouca coisa. A não ser que se você submeter um commit para uma branch ela inicie algum processo na pipeline que possa dar problema em prod ou fazer a empresa perder dinheiro de alguma forma, se você fizer um merge errado, dá revert, sobe de novo e vida que segue.
Não entendi esse vídeo, pois fala q git flow é ruim mas não mostrou no que ele é ruim, no caso q vc citou referente a ter de abrir 2,3,4 PR pra fazer um commit, eu gostaria se possível de um exemplo prático, pois não consegui visualizar como isso iria ocorrer, eu uso um flow q é baseado no gitflow e pra mim oq o git flow garante é sossego na hora de abrir uma correção e mandar pra produção tendo certeza q oq estou corrigindo é oq está em produção, que qdo vou gerarar uma versão em produção tenho certeza que estão indo as features q foram finalizadas. Agora uma coisa que sei q não funciona, é trabalhar com vários desenvolvedores usando rebase, pois o rebase quebra fluxo da branch, basicamente diz q oq tava no topo do seus commits não exite mais, como se reescrevesse o passado, eu uso rebase, mas somente se ainda não fiz push para nenhum remote, pois se fizer isso, ai já era pra todos q puxaram o commit anterior, todo mundo vai ter de puxar e qdo for subir muito provavelmente vai te de fazer force e vira uma bagunça
O rebase quebra o fluxo apenas se a branch compartilhada tiver um rebase. Esse é na real o bo. Acontece a mesma coisa quando vc aperta o revert pelo GitHub, zua tudo. O gitflow é ruim por causa da burocracia que faz com que um dev abra 4 PRs pra subir 1 commit pra produção. Quando tem outras 3 pessoas q vão aprovar de fato, ok. Mas o q mais vejo é a cena do Chaves vendendo churros pra si mesmo. Mas se o gitflow tá funcionando pra vc, só vai. Junto com a crítica ao gitflow eu expliquei uns 3 outros conceitos, o vídeo tá aí pra fazer pensar.
Sou novo e logo de cara peguei gestão em uma startup, estudei o git flow e não me desceu, o que fiz foi adaptar para a equipe: main - branch de produção, ninguém toca. develop - branch base que criamos todas as PR. release - branch quando alcançamos uma versão que irá para a main. O resto dos fluxos do gitflow não aderi, dessa forma conseguimos rastrear e versionar de forma rápida e tranquila.
Acredito que uma grande crescente no compartilhamento do gitflow foram as universidades. Pelo menos das que tive conhecimento, elas passavam gitflow como processo para os alunos.
Wow, fico muito feliz em encontrar um canal assim, diante de tantas vozes dissonantes neste vasto universo do desenvolvimento de software, ainda temos quem nos traga a razão, hahahaha!
na minha opinião, Gitflow é um bom inicio para começar a organizar o processo de desenvolvimento e no nosso caso salvou a bagunça que era quando não tinha nada e nosso "desenvolvimento" é 70% hotfix no backoffice de um erp, para alguma regra fiscal "nova", bugs e relatórios solicitados no nada para entregar em horas (kkkkkk), 25% integração com outros sistemas (nossas features que quando é validado vira release) e 5% chutando alto é mudanças significativas para chamar de novo...,e como funcionou, não pensamos se tem algo melhor, com certeza tem deve ter um processo correto para meu caso. Bom, acho q isso deve ter acontecido em muitos casos quando deu certo usar o gitflow, parece "simples" de implantar o que ocasionou o sucesso desse processo
Mas pelo que vc descreveu vcs não trabalham num cenário agiu né? As entregas são programadas aí? Pelo menos a maior parte dos erps q conheço são… pq igual falei, pode ajudar sim. Mas ainda tem muita coisa. O flow que pode te trazer problemas. E se vc mesmo tiver abrindo múltiplos PR e aprovando, vc tem provavelmente um problema
@@lucas_badico Não trabalhamos com agil, só kaban e dailys mesmo, nem entregas programadas (quem me dera) , o fluxos q adotamos aq é só o gerente sobe pra main, como eu disse, o gitflow é bom para cenários que não existe cenário e nosso caso que não lemos o artigo do cara, só pesquisamos no google "melhor forma de trabalhar com git" e tamos a 3 anos assim, depois vou ate procurar saber sobre outros jeitos de trabalhar no seu canal, esse é o segundo video q vi
Entendi o modelo do Gitflow, mas parece ser confuso orquestrar tantas branchs assim... Quanto mais branchs maior é a possibilidade de dar conflito no código entre elas não é? Eu utilizo rebase localmente na minha maquina sempre quando vou abrir um novo PR, e como uso o github cli para criar novos PR, gosto de passar as flags -m (para mergear), -d (para deletar a branch depois do merge) e -r (para fazer o rebase).
Corajoso deletar a branch logo depois… minhas branch’s eu limpo 1 vez no trimestre e olhe lá haha 🤣 Sobre a quantidade de branchs, esse nem é o BO, mas o modo do merge entre elas, vc tá no caminho certo, o caminho estreito do rebase. Outro fator q vota contra múltiplas branch’s é qual delas é a verdade? O simples é normalmente o melhor.
@@lucas_badico eu deleto pq sinceramente não vejo diferença em deletar e não deletar, nunca deu B.Ozão (ainda) quanto isso kkkkkkkkk, mas quando alguma feature vai com bug pra prod, eu restauro a branch ou crio uma nova branch baseada na main para corrigir (comparando ao gitflow seria tipo uma branch de hotfix), e repito processo, de criar o pr, merge rebase e torno a deleta-la dnv 😂😂
@@lucas_badico quais tipos de problemas você acha que pode dar em não manter a branch originais enquanto usa o rebase? Conflito de código ou algum outro relacionado?
@@hallexcosta depende do processo. As vezes alguns rebase dão errado. Ai é bom clonar a branch feature, executar rebase no clone e mergear o clone. Se der ruim no rebase, sei la, corrigiu conflito errado, vc tem a branch original, q nao pode ser mergeada, mas tá de backup. Eu faço pouco isso, normalmente em grandes rebases mas faço
Boa maninho, depois que postei tem uma galera se manifestando que tem lugares usando. Bom saber. Mas deixa perguntar, lá vcs usavam tudo? feature, fix, release, hotfix, etc...
Hum, Itaú! Localiza! Falei duas, mas tem mais aqui na manga. Acho que os extremos são um problema, as pessoas simplesmente querem definir uma solução como bala de prata ou sem utilidade. Gitflow é muito bom em determinados cenários, da mesma forma é ruim em outros cenários, tem que ver o contexto para aplicar ou não. Só meter a lenha diz muito sobre a qualidade do trabalho.
Eu nunca trabalhei com gitflow especificamente, mas já trabalhei em fluxos com essas duas branches de longa duração (main e develop), e isso nunca se adaptou ao processo da empresa. O sistema desenvolvido era instalado em vários clientes, o que eventualmente resultava em ter que aplicar correções em versões específicas, uma vez que nem todos os clientes estão na última versão lançada, ou por questões contratuais poderiam ser atualizados para a última versão e receber as novas funcionalidades. O gitflow simplesmente não tem fluxo para permitir a manutenção de versões lançadas que não sejam a última versão, nem da referências aos commits para que isso possa ser feito. Ou seja, só atrapalhava o processo de manutenção.
Bom, de fato falar levianamente é ignorância, mas eu acho q consigo dizer que de todos os flows, o Gitflow é bem ruim. O video é a sustentação disso. E se o criador concorda comigo, talvez eu não esteja tão errado assim...
Cara, acho que você exagerou haha Como qualquer coisa no mundo de tecnologia, a escolha da ferramenta depende do contexto em que você está trabalhando. Como ferramenta, entenda padrões, frameworks, bibliotecas, linguagens de programação, etc. O sucesso do seu projeto depende das boas escolhas que você faz. Por exemplo, quando a gente usa padrões de projeto de maneira exaustiva chamamos isso de over-engineering - nem todos os padrões servem para todos os projetos. Da mesma forma, gitflow não serve pra todos os projetos . Além disso, gitflow não é um padrão. Ele tá mais pra um framework. Se você estiver construindo um software que é explicitamente versionado, ou se você precisa dar suporte a múltiplas versões do seu software na natureza, e tem várias pessoas colaborando, gitflow faz total sentido. Agora se você está atuando sozinho num projeto ou em um projeto mais simples, você pode usar outros fluxos (ex: github flow) ou ainda simplificar o gitflow (ex: trabalhar apenas com 1. branch main, feature branches e tag; 2. main, dev, feature branches; 3. etc.). Talvez você tenha usado o gitflow no seu projeto de faculdade ou pessoal e ficou traumatizado... não precisa ser assim.
Haha parte do exagero é pra gerar engajamento. Mas eu realmente acho q gitflow um gmud da modinha sabe? Eu usei gitflow em empresa top, com times dinâmicos e talz, e mesmo assim não justificou. Na minha empresa eu usei um flow adaptado do trunkbased development. Não era o trunk exatamente, mas tinha coisas boas dele e das branch’s no geral.
Bastava as pessoas lerem a página do criador original do git flow kkkkk. Ele mesmo explica que git flow foi criado em outra época, com outra situação em mente. Ele mesmo elenca o GitHub flow se adequa muito melhor aos padrões de CI e CD atuais de aplicações web ou web-based
Pois, eu tbm tenho problemas com github flow. Prefiro muito mais um aprouch de features branchs que sempre mergeiam com FF Merges, e ENV/DEPLOYS e versoes sao baseadas em TAGs, nao em Branchs.
kkkkkk bom ponto. vou criar uma polêmica. como nunca trabalhei em empresa grande e normalmente no máximo 2 pessoas mexiam no código, o git sempre foi usado como um ftp melhorado com a possibilidade de voltar ao estado anterior, caso desse ruim kkk
Poh, critica sempre bem vinda. Mas eu gosto muito da estética do microfone, eu to tentando mudar um pouco ele de lugar. mas no quadro ele vai continuar aparente.
Droga, ja tinha vindo sentar a lenha, pior que o flow de git depende da necessidade do time, se gitflow nao atende, e so montar o que te atende e deu...
Caraca, 20min de vídeo pra falar. Git flow aumenta burocracia e """pode""" poluir sua árvore. Lucas, Gitflow não funciona em todos os casos, da mesma forma que trunk também não funciona No final, Git flow não é uma roubada, você só está mudando o problema de lugar. Ao invés de ter devs ruins achando que tem uma proteção com Gitflow, você vai ter Git users ruins usando git da forma errada. Pra times quem tem QA, Gitflow funciona relativamente bem. Cada caso é um caso
Então, eu não usei 20min só pra falar mal de gitflow, se você só absorveu isso. Com QAs eu já trabalhei com GITFLOW e GITHUB FLOW. No fim da no mesmo, eles tao testando código com potencial de não refletir a main branch. Bem arriscado, ainda mais em merges grandes. O 3 way merge é a benção e a maldição do GIT como um todo.
Esse conteúdo da muito sono, nao sei como vocês conseguem discutir esse monte de nada. Quer usar git flow usa, nao quer nao usa... essa discussão é uma grande bobagem
A discussão pela discussão eu concordo muito. Mas não sei se vc percebeu, por causa da discussão eu apresentei pelo menos 3 conceitos importantes da engenharia de software. 🐧
Vim pelo mano Deyvin. Ótimo canal.
Tenho simpatia pelo git flow mas nunca o utilizei de fato. Apenas nos inspiravamos nele na minha outra empresa.
Muitos fazem isso.
@@lucas_badico vir pelo mano deyvin? #Zoeira
@@EduardoCostaLisboa hahaha tbm! Mas me referia a ter ouvido falar do git flow e achar interessante
@@lucas_badico de boas! Eu curti sua explicação, não tinha visto ainda uma visão assim tão aprofundada. Eu tou pra mandar um comentário na thread principal sobre o assunto, mas ainda tou "preparando minha tese" hahah
agora você precisa dar a solução!
Antes da solução preciso explicar as bases do git. Podexa q esses vídeos estão vindo aí!
@@marcuspaulo1984 desculpa maninho, é que foram 4 meses bem turbulentos. Fechei a minha empresa, encerrando com clientes e funcionarios, garantindo q todo mundo estivesse bem... Logo logo vou voltar aos temas que deixei pra tras.
Tbm to devendo continuar mostrando o obsidian, entre outras coisas... Acredite, não são vazias minhas criticas. E perdao pela demora.
Trunk based
@@lucas_badico Se usasse gitflow isso nao teria acontecido
@@fernandofelixdonascimentoj6640 hahaha te garanto versionamento de código não foi o meu bo
A vdd é que só usa branch quem n se garante na main 😎
hahaha boa
@@marcuspaulo1984 é meme amigo!
onde eu trampo é direto na main 😎, no caso usamos trunk based, as novas funcionalidades sao encapsuladas por feature flags (if)
Eu utilizo um processo bem parecido que fiz baseado no GitFlow, como na empresa só existe eu de dev, até o momento vem me atendendo tranquilamente. Utilizo duas branchs Master e Develop, mas procuro sempre deixar as duas exatamente iguais, e vou fazendo as features em cima da develop.
Estuda o rebase mano, e as tag do git. Ajudam muito. No próximo vídeo do tema, vou mostrar o flow aqui da minha empresa. Atende times pequenos, times solos e times grandes.
A regra é clara, equipe boa joga tudo na main, todo mundo podendo fazer push, e o cd sem qa. Deu ruim, reset --hard, push --force. E o banco de dados? Ah, isso aí é detalhe besta
Gitflow estava minha lista pra ler sobre, nem vou mais haha
A propósito, cheguei tem pouco tempo. Estou gostando dos vídeos.
Se fizer sobre os outros pontos relacionados ao git, vou assistir hehe
Opa, vou trazer com certeza os outros pontos. Tenho 2 videos na lista:
Git BASICO, pra quem ta começando e tbm pro pessoal que ta precisando de backup no obsidian, onde falarei sobre:
- criar conta github
- instalar git
- clonar repo/iniciar repo
- criar commit
- abrir PR.mergear
Processos Baseados em GIt
- aonde eu falarei sobre usar ou nao merges
- pq usar rebases
- importancia de commits atomicos
- importancia do git graph
- Gihub actions e por ai vai
- cherry pick
Massa! Esse segundo me interessa mais hehe Sigo acompanhando.
Até hoje só trabalhei com algum tipo de adaptação de Gitflow. Basicamente cada empresa tem o seu, e normalmente está relacionado ao fluxo de trabalho e também CI/CD.
Mano, não é só vc. Cada empresa pega o q lhe apetece do gitflow mesmo.
Precisei ver duas vezes para entender.
Puxa… 🫥 que coisa, mas entendeu no final? Se ficou alguma dúvida manda aí
Dev há vários anos aqui. Não uso mais Git Flow não pela premissa de que ele sempre foi ruim, mas sim porque a dinâmica, ferramentas e novas visões de processos mudaram e/ou evoluíram ao lado de novas ferramentas e metodologias. À época em que Git Flow foi criado ele era ÚTIL, sim, havia algum processo formal conhecido (mesmo se, por ventura, considerarmos ruim) - a forma de ver e entregar software era diferente. Então o fato do autor do Git Flow não mais o recomendar é pelo fato que a dinâmica e cenário mudou e temos "coisas" que não tínhamos na época. Ainda assim, alguns pontos do vídeo são válidos. Dica: cuidado com as generalizações, ainda mais na nossa área onde muita coisa depende da situação.
Booa!
Muito boa a visão.
Tenho trabalhado com git flow atualmente no projeto que estou alocado (talvez por estar na Holanda hahaha), mas sinceramente, não vejo tantos problemas assim.
O que eu acho interessante sobre todos os tipo de processo Git é que, até então, em 15 anos de carreira, trabalhando para empresas multi-bilionárias, não vi ninguém utilizar os processos de Git para algum tipo de gerenciamento. Na verdade é sempre um pouco bagunçado (claro, uns mais que os outros)
O que quero dizer com isso é: é um puta preciosismo para pouca coisa. A não ser que se você submeter um commit para uma branch ela inicie algum processo na pipeline que possa dar problema em prod ou fazer a empresa perder dinheiro de alguma forma, se você fizer um merge errado, dá revert, sobe de novo e vida que segue.
Fala man, aqui na empresa a gente fala muito de gitflow e utiliza bastante, nao que isso seja um fator de sucesso, mas ajuda
Boa velho. Vcs tem time de devops essas coisas?
Não entendi esse vídeo, pois fala q git flow é ruim mas não mostrou no que ele é ruim, no caso q vc citou referente a ter de abrir 2,3,4 PR pra fazer um commit, eu gostaria se possível de um exemplo prático, pois não consegui visualizar como isso iria ocorrer, eu uso um flow q é baseado no gitflow e pra mim oq o git flow garante é sossego na hora de abrir uma correção e mandar pra produção tendo certeza q oq estou corrigindo é oq está em produção, que qdo vou gerarar uma versão em produção tenho certeza que estão indo as features q foram finalizadas. Agora uma coisa que sei q não funciona, é trabalhar com vários desenvolvedores usando rebase, pois o rebase quebra fluxo da branch, basicamente diz q oq tava no topo do seus commits não exite mais, como se reescrevesse o passado, eu uso rebase, mas somente se ainda não fiz push para nenhum remote, pois se fizer isso, ai já era pra todos q puxaram o commit anterior, todo mundo vai ter de puxar e qdo for subir muito provavelmente vai te de fazer force e vira uma bagunça
O rebase quebra o fluxo apenas se a branch compartilhada tiver um rebase. Esse é na real o bo. Acontece a mesma coisa quando vc aperta o revert pelo GitHub, zua tudo.
O gitflow é ruim por causa da burocracia que faz com que um dev abra 4 PRs pra subir 1 commit pra produção. Quando tem outras 3 pessoas q vão aprovar de fato, ok. Mas o q mais vejo é a cena do Chaves vendendo churros pra si mesmo.
Mas se o gitflow tá funcionando pra vc, só vai. Junto com a crítica ao gitflow eu expliquei uns 3 outros conceitos, o vídeo tá aí pra fazer pensar.
Sou novo e logo de cara peguei gestão em uma startup, estudei o git flow e não me desceu, o que fiz foi adaptar para a equipe:
main - branch de produção, ninguém toca.
develop - branch base que criamos todas as PR.
release - branch quando alcançamos uma versão que irá para a main.
O resto dos fluxos do gitflow não aderi, dessa forma conseguimos rastrear e versionar de forma rápida e tranquila.
Po mano, vou preparar um vídeo mostrando o que eu acho uma solução ótima pra lidar com a complexidade dos git merges
@@lucas_badico Opa, no aguardo chefe!
super da hora essa explicacao
Boa maninho!!!
Acredito que uma grande crescente no compartilhamento do gitflow foram as universidades. Pelo menos das que tive conhecimento, elas passavam gitflow como processo para os alunos.
Pô! Que desserviço! Não sabia desse detalhe…
Esperando os vídeos com as alternativas
Wow, fico muito feliz em encontrar um canal assim, diante de tantas vozes dissonantes neste vasto universo do desenvolvimento de software, ainda temos quem nos traga a razão, hahahaha!
Nois maninho, da um navegada nos outros videos... Tem muita coisa que pode ser útil. Bora construir essa comunidade de gente fera!
na minha opinião, Gitflow é um bom inicio para começar a organizar o processo de desenvolvimento e no nosso caso salvou a bagunça que era quando não tinha nada e nosso "desenvolvimento" é 70% hotfix no backoffice de um erp, para alguma regra fiscal "nova", bugs e relatórios solicitados no nada para entregar em horas (kkkkkk), 25% integração com outros sistemas (nossas features que quando é validado vira release) e 5% chutando alto é mudanças significativas para chamar de novo...,e como funcionou, não pensamos se tem algo melhor, com certeza tem deve ter um processo correto para meu caso. Bom, acho q isso deve ter acontecido em muitos casos quando deu certo usar o gitflow, parece "simples" de implantar o que ocasionou o sucesso desse processo
Mas pelo que vc descreveu vcs não trabalham num cenário agiu né? As entregas são programadas aí? Pelo menos a maior parte dos erps q conheço são… pq igual falei, pode ajudar sim. Mas ainda tem muita coisa. O flow que pode te trazer problemas. E se vc mesmo tiver abrindo múltiplos PR e aprovando, vc tem provavelmente um problema
@@lucas_badico Não trabalhamos com agil, só kaban e dailys mesmo, nem entregas programadas (quem me dera) , o fluxos q adotamos aq é só o gerente sobe pra main, como eu disse, o gitflow é bom para cenários que não existe cenário e nosso caso que não lemos o artigo do cara, só pesquisamos no google "melhor forma de trabalhar com git" e tamos a 3 anos assim, depois vou ate procurar saber sobre outros jeitos de trabalhar no seu canal, esse é o segundo video q vi
Entendi maninho! Malz a demora na resposta, só agora q vi que tem como filtrar por comentários com novas respostas
seria ótimo ter um video focado nessa parte de git que você comenta no video.
Podexa que estou trabalhando em 2 vídeos sobre git!
Entendi o modelo do Gitflow, mas parece ser confuso orquestrar tantas branchs assim... Quanto mais branchs maior é a possibilidade de dar conflito no código entre elas não é?
Eu utilizo rebase localmente na minha maquina sempre quando vou abrir um novo PR, e como uso o github cli para criar novos PR, gosto de passar as flags -m (para mergear), -d (para deletar a branch depois do merge) e -r (para fazer o rebase).
Corajoso deletar a branch logo depois… minhas branch’s eu limpo 1 vez no trimestre e olhe lá haha 🤣
Sobre a quantidade de branchs, esse nem é o BO, mas o modo do merge entre elas, vc tá no caminho certo, o caminho estreito do rebase.
Outro fator q vota contra múltiplas branch’s é qual delas é a verdade? O simples é normalmente o melhor.
@@lucas_badico eu deleto pq sinceramente não vejo diferença em deletar e não deletar, nunca deu B.Ozão (ainda) quanto isso kkkkkkkkk, mas quando alguma feature vai com bug pra prod, eu restauro a branch ou crio uma nova branch baseada na main para corrigir (comparando ao gitflow seria tipo uma branch de hotfix), e repito processo, de criar o pr, merge rebase e torno a deleta-la dnv 😂😂
@@hallexcosta eu acho arriscado não ter as branchs originais enquanto usamos rebase e talz…
@@lucas_badico quais tipos de problemas você acha que pode dar em não manter a branch originais enquanto usa o rebase? Conflito de código ou algum outro relacionado?
@@hallexcosta depende do processo. As vezes alguns rebase dão errado. Ai é bom clonar a branch feature, executar rebase no clone e mergear o clone. Se der ruim no rebase, sei la, corrigiu conflito errado, vc tem a branch original, q nao pode ser mergeada, mas tá de backup. Eu faço pouco isso, normalmente em grandes rebases mas faço
Caaaaaaadê o vídeo das soluções?
Quarta sai um video com parte da solução.
cade os videosssss explicando a solucao!! posta posta pfv
Tô trabalhando no q explica uma das alternativas! Logo logo saiii
No Vídeo você começa falando que nem uma indústria usa porém trabalhei dois anos no Itaú e nós usávamos sim o Gitflow.
Boa maninho, depois que postei tem uma galera se manifestando que tem lugares usando. Bom saber.
Mas deixa perguntar, lá vcs usavam tudo? feature, fix, release, hotfix, etc...
Hum, Itaú! Localiza! Falei duas, mas tem mais aqui na manga. Acho que os extremos são um problema, as pessoas simplesmente querem definir uma solução como bala de prata ou sem utilidade. Gitflow é muito bom em determinados cenários, da mesma forma é ruim em outros cenários, tem que ver o contexto para aplicar ou não. Só meter a lenha diz muito sobre a qualidade do trabalho.
Obrigado pelo comentário, mas não meti a lenha só não, disso tenho consciência, só nesse vídeo expliquei 3 outros conceitos.
Completamente de acordo com os pontos deste vídeo. Eu também falo sobre gitflow ser ruim e sou chamado de chato.
Booooa! Mais um do clube haha os chatos que evitam dor de cabeça kkk
Eu não sou dev. Só executo alguns terraform. E não entendi muita coisa. Mas obrigado!
Q isso, tamo junto pô!
Eu nunca trabalhei com gitflow especificamente, mas já trabalhei em fluxos com essas duas branches de longa duração (main e develop), e isso nunca se adaptou ao processo da empresa. O sistema desenvolvido era instalado em vários clientes, o que eventualmente resultava em ter que aplicar correções em versões específicas, uma vez que nem todos os clientes estão na última versão lançada, ou por questões contratuais poderiam ser atualizados para a última versão e receber as novas funcionalidades. O gitflow simplesmente não tem fluxo para permitir a manutenção de versões lançadas que não sejam a última versão, nem da referências aos commits para que isso possa ser feito. Ou seja, só atrapalhava o processo de manutenção.
É o que vc falou, cada empresa com seu processo e particularidades precisa d é um flow específico. Um nunca vai atender a todos.
Eu acho que falar que qualquer coisa é a pior solução é ignorancia... tudo depende do problema
Bom, de fato falar levianamente é ignorância, mas eu acho q consigo dizer que de todos os flows, o Gitflow é bem ruim. O video é a sustentação disso. E se o criador concorda comigo, talvez eu não esteja tão errado assim...
Mano, acredito que um vídeo sobre a solução seja interessante.
Vou preparar maninho, um dos próximos q vou gravar
Seria interessante propor alternativas ao gitflow. Sem uma sugestão do "mais correto" sua crítica fica bem subjetiva.
ta no forno um video com uma alternativa q adotamos aqui na empresa.
Vlw ai o comentario!
Massa!
Nois, tu usa ou já usou gitflow por ai?
Vi pelo mano devin depois que você falou em um video que tinha falado sobre gitflow e que ele falou que ia querer ver porque tu é muito cabeça.
Curtiu maninho?
Cara, acho que você exagerou haha Como qualquer coisa no mundo de tecnologia, a escolha da ferramenta depende do contexto em que você está trabalhando. Como ferramenta, entenda padrões, frameworks, bibliotecas, linguagens de programação, etc. O sucesso do seu projeto depende das boas escolhas que você faz. Por exemplo, quando a gente usa padrões de projeto de maneira exaustiva chamamos isso de over-engineering - nem todos os padrões servem para todos os projetos. Da mesma forma, gitflow não serve pra todos os projetos . Além disso, gitflow não é um padrão. Ele tá mais pra um framework. Se você estiver construindo um software que é explicitamente versionado, ou se você precisa dar suporte a múltiplas versões do seu software na natureza, e tem várias pessoas colaborando, gitflow faz total sentido. Agora se você está atuando sozinho num projeto ou em um projeto mais simples, você pode usar outros fluxos (ex: github flow) ou ainda simplificar o gitflow (ex: trabalhar apenas com 1. branch main, feature branches e tag; 2. main, dev, feature branches; 3. etc.). Talvez você tenha usado o gitflow no seu projeto de faculdade ou pessoal e ficou traumatizado... não precisa ser assim.
Haha parte do exagero é pra gerar engajamento. Mas eu realmente acho q gitflow um gmud da modinha sabe?
Eu usei gitflow em empresa top, com times dinâmicos e talz, e mesmo assim não justificou.
Na minha empresa eu usei um flow adaptado do trunkbased development.
Não era o trunk exatamente, mas tinha coisas boas dele e das branch’s no geral.
Bastava as pessoas lerem a página do criador original do git flow kkkkk. Ele mesmo explica que git flow foi criado em outra época, com outra situação em mente. Ele mesmo elenca o GitHub flow se adequa muito melhor aos padrões de CI e CD atuais de aplicações web ou web-based
Pois, eu tbm tenho problemas com github flow. Prefiro muito mais um aprouch de features branchs que sempre mergeiam com FF Merges, e ENV/DEPLOYS e versoes sao baseadas em TAGs, nao em Branchs.
me perdeu ao mencionar a mentoria ... beijo, sucesso!
Que bom que fora a mentoria teve algo bom.
Cade a solução ao git flow??? O que eu faço??
Pera q vai sair! Tamo trabalhando pra trazer mais vídeos por semana. Daí logo logo consigo gastar um tempo no vídeo do git rebase flow
kkkkkk bom ponto. vou criar uma polêmica. como nunca trabalhei em empresa grande e normalmente no máximo 2 pessoas mexiam no código, o git sempre foi usado como um ftp melhorado com a possibilidade de voltar ao estado anterior, caso desse ruim kkk
MAs po, o git é exatamente isso. FTP com máquina do tempo🤯
e a automação era o chefe dar um pull em prod e estava atualizado rsss
@@thiagoinfanti eu já vivi isso kkk 😹
Kkkk quem nunca. Me inscrevi no canal e te desejo boa sorte aí na jornada, e se precisar de ajuda com algum job, pode contar comigo. Abraço
Vlw maninho! Tem bastante conteúdo já pra maratonar, depois da uma olhada.
Só uma crítica, espero que seja construtiva, esse microfone na frente me incomodou demais.
Poh, critica sempre bem vinda. Mas eu gosto muito da estética do microfone, eu to tentando mudar um pouco ele de lugar. mas no quadro ele vai continuar aparente.
Nada a ver KKKKKkkk
q critíca sem sentido
Trunk based é o melhor
To preparando um video sobre trunk, tem umas coisas a serem faladas sobre ele tbm, mas é uma boa alternativa.
Droga, ja tinha vindo sentar a lenha, pior que o flow de git depende da necessidade do time, se gitflow nao atende, e so montar o que te atende e deu...
Exatamente!
Caraca, 20min de vídeo pra falar. Git flow aumenta burocracia e """pode""" poluir sua árvore.
Lucas, Gitflow não funciona em todos os casos, da mesma forma que trunk também não funciona
No final, Git flow não é uma roubada, você só está mudando o problema de lugar. Ao invés de ter devs ruins achando que tem uma proteção com Gitflow, você vai ter Git users ruins usando git da forma errada.
Pra times quem tem QA, Gitflow funciona relativamente bem.
Cada caso é um caso
Então, eu não usei 20min só pra falar mal de gitflow, se você só absorveu isso. Com QAs eu já trabalhei com GITFLOW e GITHUB FLOW. No fim da no mesmo, eles tao testando código com potencial de não refletir a main branch. Bem arriscado, ainda mais em merges grandes.
O 3 way merge é a benção e a maldição do GIT como um todo.
Esse conteúdo da muito sono, nao sei como vocês conseguem discutir esse monte de nada. Quer usar git flow usa, nao quer nao usa... essa discussão é uma grande bobagem
A discussão pela discussão eu concordo muito. Mas não sei se vc percebeu, por causa da discussão eu apresentei pelo menos 3 conceitos importantes da engenharia de software. 🐧