[Curso de Git e GitHub - 2023] Aula 7: Pull Requests

salve salve tudo beleza Professor Pietro aqui para mais uma aulinha do nosso curso de Git e github dessa vez vamos falar um pouquinho aqui sobre Power quests talvez já tenha ouvido falar disso então hoje a gente vai entender isso melhor Bora lá [Música] meu amigo minha amiga por gentileza peço aquele favorzão de você já deixar o like aqui no vídeo só clica aí é um cliquezinho rapidinho se você não está inscrito ou inscrito no canal Não deixe de se inscrever clique no Sininho também para receber as notificações Aposto que você com certeza vai aproveitar muito

do que eu tenho para passar aqui nesse canal beleza vamos lá então sem mais delongas para nossa aulinha de hoje continuação do nosso curso de introdução de de rubi na aula passada a gente fez aqui um Hand Zon botamos a boa e velha mão na massa lá e fizemos alguns testes de colaboração entre programadores distintos em ambiente privado nenhum repositório privado aí no github entre aspas né então na aula de hoje a gente fala um pouquinho sobre quests O que são os purequests vocês vão entender o que que é isso aqui hoje a gente vai

mostrar aqui visualmente qual seria o fluxo de ações que você deveria você e a sua equipe deveriam executar para que esse purequest ele ocorra da maneira adequada né falaremos também aqui de Cold review revisão de código um dos eh dos requisitos aí para que o seu sistema seja desenvolvido com qualidade né muito comum aí em empresas sérias bacana e também falaremos aqui do fluxo de ações para fazer um Cold review beleza vamos lá então purequest pedindo ajuda para que o seu código seja incluído no projeto pedindo ajuda não pedindo para que ele seja incluído E

aí Claro ajuda vem no sentido de revisar o teu código para ver se não tem alguma melhoria alguma coisa que eu possa ser feita diferente ali dentro Beleza então o público Quest ele é isso né Então pensa no seguinte aqui ó quando você envia o seu código para a sua Branch local Ah quando você comenta lá na sua frente local o código tá só na sua mão tá na sua na sua máquina ali Tá tranquilo né você ainda não entre aspas você ainda não está afetando o código do time Beleza agora quando você pede para

mesclar para integrar a sua Branch o código que está na sua Branch com o código da Branch de todo o time do projeto como um todo aí Você tá tentando contribuir com o código dos outros OK E aí isso é uma tentativa Porque dependendo de como você tá fazendo isso você pode ter seu código rejeitado Você pode ter que ajeitar o seu código Melhor arrumar ele no caso né corrigir algumas coisas para que isso seja aceite pelo time tá então aqui a motivação seria convidar as pessoas do seu time para revisar o seu código para

diminuir as chances de ah Professor Mas eu sou um bom programador eu sou uma boa programadora não você não é Seja humilde tá todo mundo está sujeito aqui a revisão de código a programadores com 10 15 20 anos de experiência precisam que outros programadores façam review dos seus códigos é natural nós somos seres humanos o erro acontece tá muito bem ou mais né ou mais você próprio pode revisar o de alguém né Então às vezes você tá chegando agora na empresa só pelo exercício de ver como que o outro faz o código Isso já é

um motivo para você melhorar o seu desempenho enquanto o programador o programador Por isso às vezes é legal que você revise o código de alguém também né tá bom aí a gente tem aqui algumas diferenças né quando o repositório é público ou quando o repositório é privado Então como é que fica a brincadeira aqui né Pensa que você tá numa empresa e o repositório lá daquele projeto ele é privado só o pessoal da empresa tem acesso ou o pessoal daquele time de dentro da empresa tem acesso Enfim então como é que você vai fazer você

vai criar sua Branch a partir da Branch de desenvolvimento né você vai fazer uma cópia da Brand principal da Branch de long termo e você vai criar tua branchinha e você vai alterar lá você vai fazer a implementação da Sua Ficha você vai corrigir o bug enfim depois que você terminou você faz o pull request da sua Branch para voltar esse código para Branch de desenvolvimento para tirar esse novo código teu com a Branch de desenvolvimento que é a Branch do time Ok então você faz um Pure Quest no fundo o que que você quer

fazer você quer fazer um murge você quer integrar o teu código com o código do time tá bom por outro lado quando o repositório ele é público então geralmente para projetos Open sourst né que que nós temos nós temos que ah o repositório ele fica lá público você clona você faz um forte do repositório original você copia todo o código do repositório original não é então uma criação de uma Branch é realmente clonar é fazer o forte desse é uma Branch também vai não deixa de ser uma Branch E você faz o a cópia desse

desse repositório inteiro público aí faz as tuas alterações e depois pede o purecast da mesma forma que você faria de forma muito singular que você faria em um ambiente privado dentro de uma empresa né tá bom E aí quem é quem são aí os revisores desse projeto eu pensei isso quem tiver o poder de revisar o teu código de sugerir que o seu código que seja aceito ou não vai depois da sequência isso tá então o fluxo de ações aqui para o público Extra é o seguinte você lá já tá com a sua Branch já

tá com seu código copiado do código original lá né Já copiou o código original alterou o teu código selecionou as coisas que você quer alterar e comentar você faz um push para sua Branch lá no seu na sua frente ainda só que lá no github e do github você pede você pede o bendito do buricquest da sua Branch no github para Brant original para Brant de desenvolvimento ou de quem quer que seja ali do projeto original para Brant de longo termo beleza é basicamente isso não tem muito segredo não tá muito bem outra coisa importante

aqui que a gente quer mencionar nessa aula é o cego int Olha só code review revisões de código o que que geralmente se olha em um processo de code review né então os programadores que vão revisar o teu código eles vão ver se o seu código está dentro das boas práticas se você é um programador iniciante que que vai acontecer geralmente você não vai adiantar o código direito você não vai saber escrever o nome das variáveis corretamente o nome das funções corretamente Às vezes você coloca uma funcionalidade dentro de um arquivo que não deveria estar

ali deveria estar em outro arquivo por causa aí da Separação das responsabilidades né enfim boas práticas de desenvolvimento de Fato né se você quer saber um pouco mais de boas práticas pesquise aí online sobre boas práticas de desenvolvimento isso certamente vai deixar o seu código melhor e a sua carreira vai ser alavancada com certeza haja visto que vão valorizar muito mais as suas entregas se as suas entregas forem boas okay e mais e mais às vezes o time Interno tem algumas Convenções que o time utiliza para manter ali as boas práticas internas da Corporação ou

daquele projeto então enfim o Code Divino serve para isso até às vezes também alguém com olhar um pouco mais experiente vê que a tua implementação pode ter um erro que você não viu enfim é para isso que serve né é a programação digamos assim não é uma programação direta mas é como se a gente tivesse envolvendo mais pessoas na criação de uma mesma funcionalidade para evitar problema no futuro tá E aí o que acontece quando você submete o teu código alguém vai olhar o teu código vai fazer sugestões aí você vai pegar e ver se

você tem que fazer aquela sugestão ou não vai debater com ele etc Então como que vai acontecer lá no github tá alguém vai fazer sugestão em sugestões no seu no seu convite ali no seu push tá no seu no seu no seu purecast perdão tá E aí você vai lá no github web tem como fazer pelo terminal tem também é um pouquinho mais trabalhoso mas tem Eu geralmente faço aí eu apelo para interface gráfica eu vou lá no githubweb mesmo e vejo os comentários veja os comentários que foram feitos nos meus comics no meu Push

no meu merj no meu request aí eu olho aqueles comentários se tiver que fazer só uma resposta via comentário também eu faço se eu realmente ver que eu preciso alterar o código eu vou lá altera o código Cometa E aí a gente fica nesse entre aspas ping pong de réplicas e tréplicas de comentários até que todo mundo envolvido no processo de code review esteja satisfeito com aquele código E aí a tendência é que o merge seja aceito Beleza então qual que seria aqui o fluxo de ações você lá implementou sua fecho e tá na sua

Branch lá no github você vai lá e pede um Power Quest para que isso seja mediado integrado com a Branch original com abrange de desenvolvimento ou cobre gente de longo termo lá né aí o revisor um vai fazer comentários você vai ver se precisa responder ou se você precisar alterar alguma coisa você vai lá e faz o que é preciso aí vem aquele mesmo revisor um ou um outro revisor e faz os comentários dele também Você vai lá e responde altera o que for preciso depois de novo essa pessoa vai lá ou uma terceira pessoa

poderia vir também e fazer os comentários dela enfim alguém no final das contas vai chegar e falar ó sobre Quest tá negado não vai dar certo cancela aqui não vamos utilizar o teu código Isso aqui vai ser refeito de um outro momento ou não ou Realmente seu código tá bom tá ótimo beleza não sei se tá bom tá ótimo mas pelo menos tá servindo pra gente passar ele para a próxima etapa do desenvolvimento de software enfim as próximas etapas pode ser por exemplo teste pela equipe de qualidade ou pode ser por exemplo já a homologação

direto para o cliente enfim depende do projeto que você tá trabalhando ou depende da empresa em si beleza maravilha então o que que a gente vê nessa aula falamos dos purecasts beleza as formas de integração de da sua Branch com as brantes do time bacana e também Falamos aqui um pouco de code review como revisar código e Como de fato é fazer com que o seu código ele vá pra frente envolvendo mais pessoas ali no processo de revisão do teu código para que você aprenda um pouco mais sobre boas práticas para que você aprenda um

pouco mais sobre como entregar um software de qualidade e o time seja beneficiado por esse processo de decisão bacana muito bem próxima aula O que que a gente vai falar a gente falar de conflitos a gente vai falar de conflitos quando você faz um purrieque quando você faz um processo de Margem Pode ser que existam conflitos Pode ser que alguém tenha alterado um trecho de código que você também alterou e na hora de fazer a integração a integração simplesmente não ocorre sozinha é preciso a intervenção humana para isso então a gente vai definir os conflitos

vai ver como resolver conflitos vai mostrar aí um fluxo de ações para quando se tenta fazer o murge e surgem conflitos tá vamos falar aqui também sobre como é importante você manter a sua Branch atualizada com abrange do time e o que que pode dar de conflito nisso E aí a gente mostra também aí o fluxo de atualizações de brants locais bacana Beleza fica por aqui então por enquanto espero que você esteja se organizando esteja conseguindo estudar e de fato tenha aproveitado aí essas aulinhas que a gente tá entregando para vocês aqui no fundo vocês

podem cachorrinho ali tá bem de boa coceira e coceira é uma fera por gentileza moçada se você ainda não se inscreveu no canal por gentileza se inscreva Ative o Sininho aí e também se possível deixa o like aqui no vídeo se tem alguma dúvida algum comentário a fazer algum elogio alguma crítica sugestão deixa nos comentários aí e a gente se vê portanto na próxima aula um grande abraço Fico por aqui até mais [Música]