Excelente vídeo! Parabéns pelo trabalho e por compartilhar o seu conhecimento! Uma das coisas que seria interessante ser explicado é como forçar a padronização do Pull Request, já vi isso no github sendo utilizado em projetos no GitHub, tem até um vídeo recente da Rocketseat sobre contribuições em projetos Open Source no Github mostrando isso sendo utilizado, mas não foi explicado como fazer o GitHub rejeitar o Pull Request que não esteja no padrão, ou por exemplo, fechar automaticamente uma issue quando no comentário tem um #ID_DA_ISSUE. Um abraço!
Onde eu trabalho atualmente, pull request fica uma semana para ser aprovado pq só tem um dev revisor que é sobrecarregado, e a empresa fomenta a competição entre os membros da equipe em que cada dev está em um projeto enorme sozinho, aí fizeram uma competição valendo 150 reais e o time ficou um contra o outro, pararam de se ajudar entre si devido a 150 reais cara, deprimente.
Show! algumas duvidas: 1) Quem fecha a pull request? quem abriu o quem reviso? 2) Se desde que abriu a pull request a branch ja teve evolucao a pull request esta desactualizada, quem deveria ficar encarregado em trazer as novas alterações da brash pra pull request ? quem abriu o quem vai fechar a pull request? Vc realmente acha que o uso de pull request para projetos que tem datas de entregas extremamente curtas com muitas alterações e uma boa pratica? tenemos bastante dificuldade por isso, pelo tempo de espera de aprovar uma pull request e depois otra pessoa ir ter que revisar isso gera muitos problemas de gargalos e freia muito otras alteracoes e entregas.
@@WaldemarNetoDevLab O conceito e teoria entendo perfeitamente mas a aplicacao e realidade para mim ainda nao e real. Paso pelo mesmo problema com o Agile. Teoria muito bonita na pratica serve para generar mais problemas e menos agil.
Vou me atrever a responder... 1) Fecha quem faz a mesclagem que pode ou não ser a pessoa que revisou ou um gerente de código. 2) Na teoria, depois que uma PR é solicitada espera-se que esteja tudo bem, mas caso seja necessário atualizar a branch, basta atualizar 😄 o código da PR é atualizado automaticamente. Espero ter ajudado! Deus abençoe.
Mano, aparentemente seu problema é com o compromisso do seu time. Nesse caso é interessante você levar para uma retrô o assunto, ou num caso maior para o squad lead, ou SM. E quem sabe fazer uma apresentação sobre a importância do pull request contínuos, para implementação das features com qualidade
Discussão saudável não tem nessa área ai não kkkkkkkkkkkkkkkk Já peguei muito dessas paradas de estar fazendo certo, mas o cara queria do padrão da empresa, só pra constar o padrão era contra tudo que era certo kkkkk mas vai discutir com gente com maior tempo de casa
4 anos atrás que esse vídeo foi publicado e essas dicas ainda são super importantes ao Abrir/Revisar PRs. Muito bom!
Mano, tu é brabo!
Agradeço por contribuir com suas experiências. Está me ajudando bastante.
3 anos e continua sendo um vídeo incrível ! Parabéns pelo conteúdo mano!
Haha boas praticas são eternas
Ótimo vídeo!
Excelente vídeo!
Parabéns pelo trabalho e por compartilhar o seu conhecimento!
Uma das coisas que seria interessante ser explicado é como forçar a padronização do Pull Request, já vi isso no github sendo utilizado em projetos no GitHub, tem até um vídeo recente da Rocketseat sobre contribuições em projetos Open Source no Github mostrando isso sendo utilizado, mas não foi explicado como fazer o GitHub rejeitar o Pull Request que não esteja no padrão, ou por exemplo, fechar automaticamente uma issue quando no comentário tem um #ID_DA_ISSUE.
Um abraço!
Dicas valiosas. Muito obrigado
Ótimo vídeo Waldemar! Detalhes diários que mesmo zelando pela qualidade cometemos todas as falhas apontadas.
Mais um vídeo excelente parabéns pelo conteúdo irmão.
Onde eu trabalho atualmente, pull request fica uma semana para ser aprovado pq só tem um dev revisor que é sobrecarregado, e a empresa fomenta a competição entre os membros da equipe em que cada dev está em um projeto enorme sozinho, aí fizeram uma competição valendo 150 reais e o time ficou um contra o outro, pararam de se ajudar entre si devido a 150 reais cara, deprimente.
Uma coisa que ajuda a manter o padrão dos PR é ter um arquivo PULL_REQUEST_TEMPLATE na raíz do repo (não tenho certeza se isso é feature só do gh)
👏👏👏👏👏
Mais um ótimo vídeo, muito útil
Top mano
boa irmao!!!
Conteúdo muito bom e melhor em português, mais um inscrito
nao sabia que rodrigo santoro tb programava
Muito bom
Muito bom!! ;)
Compartilhado.
Show! algumas duvidas:
1) Quem fecha a pull request? quem abriu o quem reviso?
2) Se desde que abriu a pull request a branch ja teve evolucao a pull request esta desactualizada, quem deveria ficar encarregado em trazer as novas alterações da brash pra pull request ? quem abriu o quem vai fechar a pull request?
Vc realmente acha que o uso de pull request para projetos que tem datas de entregas extremamente curtas com muitas alterações e uma boa pratica? tenemos bastante dificuldade por isso, pelo tempo de espera de aprovar uma pull request e depois otra pessoa ir ter que revisar isso gera muitos problemas de gargalos e freia muito otras alteracoes e entregas.
@@WaldemarNetoDevLab O conceito e teoria entendo perfeitamente mas a aplicacao e realidade para mim ainda nao e real. Paso pelo mesmo problema com o Agile. Teoria muito bonita na pratica serve para generar mais problemas e menos agil.
Vou me atrever a responder...
1) Fecha quem faz a mesclagem que pode ou não ser a pessoa que revisou ou um gerente de código.
2) Na teoria, depois que uma PR é solicitada espera-se que esteja tudo bem, mas caso seja necessário atualizar a branch, basta atualizar 😄 o código da PR é atualizado automaticamente.
Espero ter ajudado! Deus abençoe.
Mano, aparentemente seu problema é com o compromisso do seu time. Nesse caso é interessante você levar para uma retrô o assunto, ou num caso maior para o squad lead, ou SM. E quem sabe fazer uma apresentação sobre a importância do pull request contínuos, para implementação das features com qualidade
11:41 cara concordo total, o cara revisa um pedacinho, ai voce ajusta e tem mais coisa. aff.
Hahaha essa é complicado 🤣
Vídeo maneiro! ;)
Achei que era Rodrigo Santoro kkkkk
Do gueto :D
Kkkk
Discussão saudável não tem nessa área ai não kkkkkkkkkkkkkkkk
Já peguei muito dessas paradas de estar fazendo certo, mas o cara queria do padrão da empresa, só pra constar o padrão era contra tudo que era certo kkkkk mas vai discutir com gente com maior tempo de casa