[Curso de Git e GitHub - 2023] Aula 6: o que são branches?

salve salve meu amigo minha amiga tudo beleza Professor Pietro por aqui hoje continuando o nosso curso de guite github falando sobre branches já ouviu falar de brants vamos lá então [Música] antes de mais nada não tem como eu preciso pedir esse favorzaço já deixa o like no vídeo me ajuda por favor se inscreva no canal Ative o Sininho para receber as notificações de próximas aulas e próximos cursos que eu Estarei lançando aqui gratuitamente para vocês bacana não perca de verdade e a gente tá sempre trabalhando para o melhor aqui no canal é isso que faz

sentido para mim por favor não deixe de fazer isso Bom vamos lá então sem mais delongas para o nosso curso de rubi Relembrando o que vimos na aula anterior a gente viu lá então como verificar o histórico de alterações de forma prática né a gente botou a mão na massa lá e viu como dar uma vasculhada nas alterações que a gente fez nos últimos comics que nós fizemos beleza na aula de hoje a gente volta um pouquinho aqui para a parte conceitual e a gente vê algumas coisinhas como modelos de controle de versão Então veja

quando tá trabalhando em equipes tem vários modelos que eu posso usar para que as minhas linhas de publicação de software fiquem mais robustas porque a gente evite bugs evite erros para que a gente muitas vezes consiga entregar continuamente e de forma integrada o software para o cliente da forma mais transparente possível para que o cliente não sinta que as atualizações são sabe um pé no saco e tal essa é a ideia Beleza então a gente vai falar aqui de branches brants do tipo state brands do tipo release e as brands criadas para implementação de features

Então eu tenho brants que elas mantém um estado atual do meu software Elas têm branches que são específicas para uma versão específica do software ou às vezes tem branches aqui que são só para implementação de uma feature ou da correção de um bug e tudo mais os tipos de branques que a gente vê aqui os modelos de controle de versão são justamente o de Branch única o github flow e o Git Flow inclusive se você der uma agulhada você provavelmente vai encontrar artigos e elaborando muito mais do que eu tô trazendo para vocês aqui nessa

aula tá sobre o Branch única githubflow e geech de state release e de features cada Brand pode ter um propósito distinto como eu disse uma branque ela pode servir já para galera de testes fazer teste naquela Branch uma outra uma outra Brand pode servir para que depois que a galera interna da empresa fez teste para que isso vá para o cliente testar cliente testou homologo tá tudo certo aí tem uma outra Brand que é a brente de produção Então você joga para essa Branch de produção e aí quando você publica nessa branque de produção o

cliente final quer dizer usuário do nosso cliente vai ter acesso a esse sistema já rodando bem bonitinho lá geralmente dentro de uma esteira de produção de continhos integration continess delivery é o famoso csd você provavelmente já ouviu falar disso né aqui a gente já entra no terreno dos Devotos e tudo mais tá mas a gente não vai não vai elaborar muito nisso Fica tranquilo só Entenda como que a gente vai usar de publicação de código distintas para funções distintas tá existem diferentes modelos diferentes fluxos e depende muito da empresa ou do projeto no qual você

tá trabalhando bacana muito bem Então olha só diferenciando aqui as Bentes de state de release e de features as brantes de state digamos assim as branches principais elas são chamadas Brant long Running long Running do inglês para o português são brants que elas ficam vivas por um longo tempo São braint que existem no longo prazo tá eu tenho geralmente a mente a Branch Man a mente Man a trilha principal e a gente pode ter também Abrante de velope se você entrar numa empresa e ver as brantes do Git do github com esses nomes você pode

imaginar já que você tá falando de Brant que no longo prazo Ok essas brantes elas devem ser estáveis a gente tem que evitar o máximo que publicar bug nessas nessas branchs Ok tem que ter um controle do Dev aí não da equipe para que não seja passado bug para essas braints por quê Porque elas tem que ser estáveis Ok e elas refletem os estágios do ciclo de desenvolvimento de software aqui eu tô falando mesmo de engenharia de software de metodologias ágeis de contínuos integration contínuos delivery csd tá geralmente a gente não faz convite diretamente nessa

Branch geralmente a gente cria uma brente à parte implementa feature na Branch à parte e aí o que a gente faz é da nossa nova Branch pedir um público Quest ou um Marge para a Branch principal ou a Branch de velope Beleza se você não entende isso direito por enquanto fica na tranquila acompanha aqui depois na prática você vai entendendo o que que é Tá mas é bom que a gente passa por essa parte teórica mas nós temos aqui as brants short Live então Brand short livre ela tem um ela tem um começo meio e

fim específico ela não vai ficar existindo ao longo de todo o ciclo de vida do software a Brant short livre ela tem uma vida curta né geralmente Então essa Branch que eu uso para implementar feature ou Brand que eu uso para implementar fixs ou corrigir bugs é nova funcionalidade então como eu disse ó voltando eu pego geralmente a parte deixa apagar um pouquinho aqui nessa poluição visual é geralmente posso pegar um código que tá na minha branque de develope por exemplo eu crio uma brecha de feature Tá difícil E aí essa Brand de feature aqui

ela já é ela já não é mais long Running Adela pelo One Runner ela tá existindo todo o tempo já me abrange de feature ela vai ser short livre ela vai ter começo meio e fim enquanto eu tiver implementando a minha nova Fiat Branch ela vai existir por isso que eu terminei de implementar essa Branch ela foi ela foi mergulhada nela foi misturada mesclada com alguma das branches de longo prazo aí eu já posso pensar em até apagar essa minha Branch de feature tá a mesma coisa para correção de bugs Então essas brants são focadas

em novas funcionalidades correções refaturamentos prova de conceito e etc beleza geralmente elas são deletadas após a integração com alguma Branch com alguma Branch que já é de longo prazo beleza e aqui a gente já entra nos modelos de brants né nos modelos de desenvolvimento de software propriamente dito tá eu posso ter aqui a boa e velha Brant única poucas ou uma única Branch é uma trilha só de komix vai racha é geralmente quando a gente tá trabalhando aqui com projetos pequenos por exemplo se você tá trabalhando lá com a sua disciplina de orientação objetos e

tem uma série de códigos que o professor passou e que você quer comentar você não vai precisar ficar criando várias brands para vários códigos diferentes vai lá e cria Cometa tudo na mesma Branch e vai que vai né é um projeto seu só você vai mexer com ele você não tem muita muita seriedade nesse projeto então você pode usar uma branchi única tá esse é o modelo mais simples Ok geralmente utilizado quando se tem uma única pessoa mexendo no código tá muito comum em projetos pessoais Como eu disse para você aqui então basicamente Ó você

tem uma única trilha de publicações né como eu disse aqui ó é uma única Branch eu vou chamar ela de Man e é uma branque de longo prazo porque tudo vai sendo coitado nela cometi um Comet 2 a alteração 3 com 23 enfim beleza mais simples que tem Maravilha próxima guite hubflow esse modelo ele não é tão enxuto como o modelo da Brant única mas ele já é um modelo um pouquinho mais elaborado para você trabalhar em equipes só que de uma forma mais enxuta você não vai ter uma única Branch Mas você vai ter

é uma coisa mais simples aqui vocês vão ver visualmente vai ficar fácil de entender o que acontece aqui ó você tem apenas uma Branch de longo prazo beleza uma brecht de longo prazo sem problemas só que daí que que vai acontecer quando você foi implementar uma nova feature quando você for corrigir algum bug você abre uma nova Branch a partir daquela Ok E aí você vai implementar o que você precisar nessa nova Branch e depois que você implementar o que você precisava Você mistura você mescla você integra com a Branch longo prazo e apaga a

Branch Abrante filha digamos assim né a Brant de short terme a short livre de curto prazo então visualmente como é que ficaria Você tem uma lá você tem uma trilha de publicação principal que ela é de longo prazo né que essa de baixo aqui ó que vocês estão vendo né então os convites principais eles estão ali ó Ok e que acontece imagina que você tinha um comitê lá beleza o seu sistema tá no estado aqui no estado um que eu vou chamar vai aí você vai precisar implementar uma nova Fischer você faz você faz uma

nova Branch e a partir da Branch original você cria uma brente separada para ir fazendo os teus convites da sua nova feature chegou na finaleira aqui ó chegou na finaleira terminou de implementar a tua ficha você tá certo que a tua ficha já terminou você faz um murge você faz um purriequest para que você comete todas as alterações da tua Branch na Brant principal você faz um mês você faz um pull request E aí o seu sistema principal ele vai ficar no estado 2 né que que eu tive aqui de bom eu tive de bom

que eu tinha um monte de lixo que eu ia comentando lixo né eu tinha etapas intermediárias que eu tava comentando na minha Branch menor que eu não precisei salvar na brante maior para não confundir a cabeça do povo não virar bagunça né para não virar bagunça com uma equipe inteira se num segundo momento ali eu tiver por exemplo que corrigir um bug eu crio uma Branch só para corrigir o bug vou fazendo os comitis beleza corrigir o bug terminou faço um erro de faço purriequest para mim abrange principal ok uma única brech long Running né

é o modelo mais simples que nós temos E aí o modelo mais estruturado mais robusto seria duas ou mais brants de longo prazo que seria que o modelo do Git Flow tá então aí a gente tem duas ou mais Branch de longo prazo e aí de novo para cada nova sítio para cada novo bug que a gente for corrigir a gente abre uma Branch à parte Então como é que fica isso né visualmente que que tem ó geralmente a Branch mais importante é Amém é a long Running ela não pode ter bug nela assim você

tem que evitar desestabilizar essa Branch a Qualquer Custo porque porque geralmente essa Branch aqui é o que é ela tem o código que o usuário final já tá tendo acesso você não quer você não quer deixar o sistema fora do ar você vai manter essa Branch sempre bonitinha ela é uma branque de longo prazo Tá o que que você faz portanto você cria uma brente que ela é similar abrange principal ela também é de longo prazo Mas ela é utilizada para receber as dos desenvolvedores Digamos que ela é uma Branch que ela é uma espécie

do clone da Branch principal só que você pode fazer testes nela você pode ir colocando novas features nela para testar para homologar e tudo mais né Então você nunca faz comites de uma feature específica né ó tá vendo que essa Branch aqui ó essa Branch é mais acima aqui ela já é uma Branch de feture né Veja implementei uma nova feature fiz o verde com a bright de desenvolvimento aí eu jogo isso aqui para equipe de teste eu jogo para o cliente testar homologo tá tudo certinho Ah tá beleza Ah não cheguei aqui vi que

tinha um bug vi que tinha um bug na feed que eu implementei Opa espera aí então vamos corrigir esse bug numa Branch à parte corrigir o bug tá tudo bonitinho a equipe de de que a equipe de teste testou o cliente já homologou beleza aí a gente joga pra Brant principal lá para o cliente final para o usuário final quem sabe ter acesso a essa nova Fiat com o bug já corrigido então a gente Evita desestabilizar o sistema tendo uma Branch aqui de longo prazo intermediária Tem empresas que tem mais de uma Branch intermediária inclusive

né enfim esse aqui é o modelo modelo do Git Flow bacana belezinha muito bem chegando aqui no finalmente da aula Olha só como é que a gente faria então para a gente trocar de Brant né Então imagina que você acabou de fazer o clone do projeto na sua máquina você tá lá na Brant Man você tá na Brant Long Live aqui Digamos que essa aqui é Amém né E você quer você quer fazer uma uma correção de um bug por exemplo né Aí você faz um kit checkout jogando o seu ambiente local para uma Branch

nova ou uma Branch que já existe mas que não seja a principal uma brente de feature por exemplo ou uma Branch de Fix de Nova funcionalidade como essa de feature aqui ou uma branque de correção de se for o caso uma Branch short livre aí você altera né você altera tudo que você precisa você comita você dá o push quando você tá feliz com isso tudo na sua Branch local você pede para que as suas alterações da sua branque local sejam jogadas de volta para aquela Branch Long Live lá para aquela Brant de longo prazo

beleza essa é a ideia ah professor não tô entendendo isso ainda fica tranquilo fica tranquila Conforme você for usando isso conforme você vai trabalhando você vai aprendendo isso namorarzinho fechou Beleza então o que que vimos nessa aula a gente falou aqui olha só de modelos de controle de versão das brantes de long Running e short short leave né as brantes de estado e as brantes de release e feature a gente viu aqui o modelo de Brant única o giflow e o Git Flow tá E também fechamos aqui com o fluxo de ações e o kit

checkout sobre como trocar de branches para implementar o seu código o que veremos na aula a gente vai simplesmente botar a mão na massa de novo a gente vai mexer com um ambiente privado como se a gente tivesse uma empresa privada colaborando com outros com outros colegas de desenvolvimento a próxima aula será bem legal será a mão na massa belezinha maravilha então não se esqueça de se organizar Porque sem organização você não estuda e também você não publica código decente bacana muito bem Agradeço por tanto que você tenha vindo até aqui se você chegou aqui

e ainda não deixou o seu like por favor deixa o like aqui manda esse vídeo para quem você acha que precisa entender um pouco mais de brants Né manda lá pra galera que nunca viu o que que é um Git Flow ou um github Flow isso aqui certamente vai fazer diferença caso você chegue em uma empresa e você não saiba trabalhar com brands bacana e olha se possível se inscreva no canal Ative o Sininho e deixe nos comentários aqui caso você tenha alguma dúvida fechou show de bola fica por aqui até mais [Música]