Mas e como ficam os PR's ou MR's? Achei mais complicado do que realizar o trabalho normalmente sem isso. Principalmente a parte de não ter um code review ai (provavelmente deve ter, mas eu não vi isso no vídeo). É bem mais fácil manualmente criar main -> develop -> feat/minha_func e depois criar o PR/MR pra develop. E assim que tudo tiver aprovado, só apertar o botão merge mesmo.
o ruim do git flow, é que não é fexivel com o github, tipo vamos supor que tenho uma aplicação que eu preciso fazer um pull request na develop para rodar meus testes CI, ai não tem jeito, tem que fazer na mão mas com isso não pode-se mais fazer `git flow feature finish` pois ai o codigo vai mergear com a develop no git local sem ter passado pelos testes que iriam ser inicializados se fosse por pull request...
LINUXTips como funciona o processo de code review e aprovacao do merge request agora ( antes faziamos o merge direto para a branch remoto) ja que ele é feito localmente agora, ou no gitflow cada um cria um merge request do seu develop local para a develop remoto ja que as feature foram mergeadas local?
bom dia! 5:10 da manhã, Sorocaba-SP. Show consolidou os conhecimentos sobre git flow! Mano sensacional!. Eu fiquei com uma dúvida, a versão que vai para dev é a 1.1?. Depois do bug fix.
tableless.com.br/git-flow-introducao/ Encontrei esse link e pelo que ele fala na sessão de HotFix parece que devemos realizar merge tbm para a Develop ...
Video excelente como sempre. To usando uma ferramenta para desenhar diagramas chamada Whimsical, acho mais fácil que o Canvas da uma fuçada depois. Vou colar na live da roxinha ;)
Na minha experiência GitFlow leva a um re-review do mesmo código a cada merge em uma branch de environment, commit hash podem se perder e precisar de rebases, aumenta o lead-time de entrega de novas funcionalidades. 😅
Jefferson com sua permissão, para saber em qual terminal estamos, tem uma opção legal para ficar igual ao seu terminal,Para exibir o branch atual, precisamos alterar a variável PS1. Basta adicionar o código abaixo no fim do arquivo .bashrc ou do .bash_profile (ambos se encontram na home do usuário ~/): export PS1='\u@\h\[\033[01;34m\] \w\[\033[0;32m\]$(__git_ps1 " (%s)")\[\033[01;34m\]$\[\033[00m\] ' Rode o comando source ~/.bashrc ou source ~/.bash_profile para recarregar e ver a alteração sem precisar reiniciar o terminal. pode alterar a cor se precisar , verde , vermelho etc é so explorar!
Achei muito bom o vídeo! bem instrutivo. Só fiquei meio perdido com a separação da Branch de Develop e da Feature Branch. Em teoria elas seriam a mesma não? Pensei que: se estou desenvolvendo e não é erro provavelmente é a uma feature. Pensei errado?
As features branches são criadas para que várias pessoas trabalhem ao mesmo tempo naquele sistema.. depois que as features são testadas e aprovadas, elas podem ir pra develop e depois pra uma release.. se vc trabalha num projeto pequeno, pessoal, a develop e a feature branch é quase a msm coisa mesmo.. mas em equipes grandes é ideal que haja essa separação...
Obrigado pela resposta. Então todos trabalham as features, o que for validado segue para develop que é um "agrupamento" do que irá para a main. Nele pode não ter todas as features, por exemplo
não vi tudo, mas não esquece do gitk e do git-gui, muito úteis graficamente.
Mt bom!
Da Branch: Feature para a Release, em vez de usar o git merge, não seria melhor usar o comando git rebase?
Mas e como ficam os PR's ou MR's? Achei mais complicado do que realizar o trabalho normalmente sem isso. Principalmente a parte de não ter um code review ai (provavelmente deve ter, mas eu não vi isso no vídeo). É bem mais fácil manualmente criar main -> develop -> feat/minha_func e depois criar o PR/MR pra develop. E assim que tudo tiver aprovado, só apertar o botão merge mesmo.
o ruim do git flow, é que não é fexivel com o github, tipo vamos supor que tenho uma aplicação que eu preciso fazer um pull request na develop para rodar meus testes CI, ai não tem jeito, tem que fazer na mão mas com isso não pode-se mais fazer `git flow feature finish` pois ai o codigo vai mergear com a develop no git local sem ter passado pelos testes que iriam ser inicializados se fosse por pull request...
23:14 Dessa maneirinha bonitinha de ai meu Deus
Sempre foda. Obrigado, Jeferson!
Simples como voar. Vaiiiiiiiiiiiii
Opa professor, quando o senhor puder postar o vídeo do GreyLog.
assistindo! gostei do teu modo de ensinar e de se expressar. não lento rsrs! bora lá assistir
LINUXTips como funciona o processo de code review e aprovacao do merge request agora ( antes faziamos o merge direto para a branch remoto) ja que ele é feito localmente agora, ou no gitflow cada um cria um merge request do seu develop local para a develop remoto ja que as feature foram mergeadas local?
Tem o 'git flow help' mano
Tem o help mano: git flow help
Que conteúdo fodaaaaaaaa, direto ao ponto, parabéns linuxTips..
bom dia! 5:10 da manhã, Sorocaba-SP. Show consolidou os conhecimentos sobre git flow! Mano sensacional!. Eu fiquei com uma dúvida, a versão que vai para dev é a 1.1?. Depois do bug fix.
Ricardo, também fiquei com essa dúvida, pq se mandar outra merge vai voltar o bug que foi corrigido no HotFix. @LINUXtips como fica nesse caso?
tableless.com.br/git-flow-introducao/ Encontrei esse link e pelo que ele fala na sessão de HotFix parece que devemos realizar merge tbm para a Develop ...
Gitflow é um pesadelo. PESADELO. Menos é mais.
trunk-based FTW. Especialmente em desenvolvimento de IaC, não vejo pq usar git flow.
Bora!!!!
Maravilhosamente é o estilo desse shell! :o
O que acha do Trunk Base Development? Bão ou não?
Sim sim, eu vou falar dele no sábado!
Acho que é mais simples e mais eficiente pra IaC. Bão.
#vai muito bom
Sensacional.
Show, aprendi rapidão
Video excelente como sempre. To usando uma ferramenta para desenhar diagramas chamada Whimsical, acho mais fácil que o Canvas da uma fuçada depois. Vou colar na live da roxinha ;)
Na minha experiência GitFlow leva a um re-review do mesmo código a cada merge em uma branch de environment, commit hash podem se perder e precisar de rebases, aumenta o lead-time de entrega de novas funcionalidades. 😅
Jefferson com sua permissão, para saber em qual terminal estamos, tem uma opção legal para ficar igual ao seu terminal,Para exibir o branch atual, precisamos alterar a variável PS1. Basta adicionar o código abaixo no fim do arquivo .bashrc ou do .bash_profile (ambos se encontram na home do usuário ~/):
export PS1='\u@\h\[\033[01;34m\] \w\[\033[0;32m\]$(__git_ps1 " (%s)")\[\033[01;34m\]$\[\033[00m\] '
Rode o comando source ~/.bashrc ou source ~/.bash_profile para recarregar e ver a alteração sem precisar reiniciar o terminal. pode alterar a cor se precisar , verde , vermelho etc é so explorar!
Vlww pela aula mestre !
Qual é o terminal e tema utilizado no vídeo?
O terminal eh o guake mano.
Pô muito interessante o assunto e a aula foi super bem apresentada! Conteúdo muito massa!
o que significa 'git commit -m "..." * '?
seria a mesma coisa de dá um 'git add .' e depois 'git commit -m "..." '?
Não não, eh somente para fazer o commit de todos os arquivos que modificamos
@@LinuxTips ahhh legal!! não sabia que tinha fazer commit somente de alguns arquivos no staging area. Valeu!!
Achei muito bom o vídeo! bem instrutivo. Só fiquei meio perdido com a separação da Branch de Develop e da Feature Branch. Em teoria elas seriam a mesma não? Pensei que: se estou desenvolvendo e não é erro provavelmente é a uma feature. Pensei errado?
As features branches são criadas para que várias pessoas trabalhem ao mesmo tempo naquele sistema.. depois que as features são testadas e aprovadas, elas podem ir pra develop e depois pra uma release.. se vc trabalha num projeto pequeno, pessoal, a develop e a feature branch é quase a msm coisa mesmo.. mas em equipes grandes é ideal que haja essa separação...
Obrigado pela resposta. Então todos trabalham as features, o que for validado segue para develop que é um "agrupamento" do que irá para a main. Nele pode não ter todas as features, por exemplo
@@pedroneto1768 Isso aí!
#sensacional
copo de requeijão jef, ai sim!
já entregou projeto com repositório vazio, Caio? hahahhaha
Trunk-based development
#linuxtipsmetrouxeaqui #obrigado
SENSACIONAL!
SÓ CONTEUDO DE PRIMEIRO! Sua mulher vai me desculpar, mas vc eh um homão da porra! Obrigada por todo o conhecimento passado
❤️❤️❤️
Jefferson agora parece um NATO TH-camR LOURO, kkkk
branch MAIN 💪😍😍
a luta é pra acabar com os fundamentos racistas sob os quais ancoramos nossos conhecimentos. #vaaaiii
@@cincoeuzebio
Qual o problema com o nome master ? 😅
#giropops
#sucodemanga
Tem tanto Amain que fica impossível não funcionar!
suco de manga kkkkk
Assunto interessa mas infelizmente não consegui assistir, o jeito gritando que você fala é muito cansativo, só por Deus