GIT: Mini Curso para Você Sair do Zero! (Aprenda em 45 Minutos)

se você já começou a programar e ainda não sabe na dica de nada de Git eu sinto dizer que você está dando bobeira junto com suas habilidades de programação é necessário aprender a versionar seus códigos até porque nós fazemos muita caquinha Enquanto estamos aprendendo e saber reverter o que fizemos e recuperar códigos e também dados é essencial preparamos um mini curso bem direto sem enrolação para você não perder tempo e poder voltar aqui sempre que precis prar consultar o vídeo tá todo separado por capítulos assim toda vez que Pintar alguma dúvida em algo específico você pode assistir o pedaço [Música] novamente como bom YouTubers então nós precisamos te engajar primeiro pedindo para você se inscrever aqui no código fonte TV se esse vídeo te ajudar de alguma forma deixe também um like compartilhe para poder ajudar outras pessoas que precisam começar a usar o Git e nada disso seria seria possível sem a parceria incrível que temos aqui com a holinger quem acompanha o código Font TV sabe que somos clientes deles e usamos de verdade o VPS da hostinger em nossos projetos aqui no canal está lotado de vídeos usando das soluções de hospedagem da hostinger o VPS é o nosso queridinho tem armazenamento SSD certificados SSL gratuitos e você pode instalar e reinstalar o que quiser nele nós por exemplo curtimos usar muito ele com contêiners ainda tem um recurso muito legal que é criar uma imagem de uma máquina como backup Então se algo der errado você em poucos segundos restaura tudo como estava antes Isso sim que é praticidade pra conhecer essa solução da rger e ainda ganhar um desconto nosso é só ir aqui ó no primeiro link que tá na descrição do vídeo se você chegou aqui no vídeo Provavelmente você já deve saber do que o Git se trata ele é um sistema de controle de versão que pode ser usado para muitas coisas mas é geralmente usado por nós programadores ele foi desenvolvido pelo mesmo criador do Kernel do Linux o Linux torval é de código aberto e depois do lançamento em 2005 caiu nas Graças dos programadores com ele você consegue controlar a versão do seu código no seu próprio computador e sincronizar as mudanças para um servidor remotamente o que possibilita o trabalho de centenas de desenvolvedores em um repositório único sem que um atrapalhe o outro durante o desenvolvimento essa foi justamente a ideia na criação do Git ele era a solução para controlar os contribuidores do kerne do Linux se funciona com eles com centenas de contribuições funciona para quase tudo hoje o Git tem versões pros principais sistemas operacionais Linux Mac OS e Windows então não importa o sistema que você use e nem mesmo o ide Aliás a instalação pode ser por linha de código e no Windows através de um instalador disponível no site Git scm. com corre lá instala e depois volta aqui no vídeo e dependendo do ide você consegue usar o Git de forma visual mas é importante entender o conceito por trás dos comandos Pois é justamente ele que irá te ajudar a não fazer caquinha durante o uso aqui vamos só usar o terminal mesmo mas com algumas pitadas aí do vs code o primeiro comando que vamos aprender é para configurar o Git é necessário no mínimo configurar o seu nome e o e-mail para que toda vez que você versionar algo com ele fique registrado o seu usuário para configurar o e-mail Então a gente vai em Git config Global tá a gente coloca o traço traço Global Lembrando que isso pode ser tanto local como de sistema Então dependendo do repositório você pode configurar outro nome inclusive coloca user. name E aí entre aspas o nome pro e-mail acaba sendo bem parecido né pra gente verificar a configuração a gente pode colocar o global e o traço traço list ele mostra todas as configurações que a gente tem se a gente colocar só o list ele mostra todas Inclusive a de sistema e a de local também e se você quiser configurar local é só tirar ali o traço traço Global a gente pode colocar config user pname e o nome nesse caso a gente nem tem um repositório local ainda então não não funcionaria vamos aprender a criar um novo repositório ou clonar um repositório já existente nessa pasta que tá vazia ainda a gente pode criar alguns arquivos vou criar um index HTML botar style.

css e scripts. js só para simular aqui um projeto web e pra gente inicializar o nosso repositório basta digitar Git init e ele já está pronto inclusive ele mostra que ele cria uma pasta pon Git lá dentro então se a gente explorar essa pasta a gente vê que ele já criou ali uma estrutura do próprio Git existe uma outra forma de se criar o repositório que é o Git init e a gente coloca o parâmetro Bear dessa forma toda essa estrutura vai pra raiz mas esse é um tipo de repositório diferente tá geralmente a gente usa isso para ficar só armazenado lá então ele tem e outras funcionalidades agora outra forma bem comum também é a gente clonar um repositório que já existe né Eu vou pegar um projeto que a gente já tem aqui no github posso colocar ó justamente com o Git Clone eu coloco o endereço né o ponto Git aí eu coloco também o nome da pasta se eu não tiver já criado ele pode criar a pasta pra gente e aí ele já vai baixar todos os arquivos desse projeto e criar automaticamente o Git né veja que tá tudo lá então uma vez que a gente tem o projeto remoto é é tranquilo da gente apagar localmente e também puxar novamente obviamente tem que est sincronizado né o projeto remoto tem que tá todo atualizado para entender o funcionamento do Git é preciso ter em mente como ele foi concebido os arquivos com os seus códigos que aparecem na pasta não são sincronizados automaticamente é preciso que você informe ao Git de quando suas mudanças estão prontas para serem versionadas então você pode modificar à vontade testar errar criar apagar arquivos e quando finalmente estiver ok Você pode colocar eles no repositório Mas calma que isso não é uma um copia e cola no Git existem dois estágios até os arquivos serem efetivamente versionados no repositório nessa imagem dá para compreender bem Toda vez que você cria um arquivo na pasta do projeto podemos considerar que ele está na sua pasta de trabalho ou no working directory ali Você pode adicionar remover editar o quanto você quiser a próxima etapa a gente chama de indexar ou organizar os arquivos que irão pro repositório esse local nós chamamos de Stage ou palco né Nós já vamos ver como adicionar ele lá nesse momento esses arquivos já estarão em um lugar especial e o arquivo no working directory pode ser modificado que não vai fazer diferença a próxima etapa é colocá-los efetivamente no repositório para isso fazemos algo chamado com ou confirmação uma vez feito isso Nós criamos um histórico de mudanças o arquivo sai do Stage e está pronto para uma nova mudança com a mudança indo efetivamente pro repositório ele será atrelada à versão anterior onde a versão mais atualizada ficará marcada com head ou seja ela será a cabeça de outras versões do mesmo arquivo Vamos ver isso na prática vamos adicionar remover e brincar com working directory e o state a gente pode fazer algumas alterações aí no no arquivo vou colocar só um título e um H1 agora que eu fiz essa alteração a gente pode voltar aqui no terminal e colocar um Git por exemplo o nome do arquivo que a gente alterou um Git index HTML uma outra forma também se a gente tiver mais de um arquivo modificado ao mesmo tempo por exemplo eu posso criar uma função aqui criar uma função bem simples e aqui no Style também por exemplo a gente já vai ver daqui a pouco mas a gente tem a opção chamada Git status e é lá que a gente consegue ver aonde tá os nossos arquivos então a gente vê que já tem um arquivo no no Stage e tem dois que ainda não estão então para adicionar a gente pode colocar o Git AD o nome de cada arquivo ou um Git AD ponto e aí ele leva todos que não estão no stage para dentro do Stage existe também alguns outros parâmetros como menos a que você na verdade vai atualizar só Quem ainda não entrou ali no Stage e você pode também fazer isso por seleção por exemplo asteristico pcss vai dar um vai colocar no Stage todo mundo que for ponto CSS O interessante é que a gente já tem aqui ó se a gente olhar no status todos os arquivos se eu quiser por exemplo fazer alguma modificação aqui ó eu vou ter uma versão que já está no Stage e uma versão que está modificada mas só local né no diretório de trabalho e se eu quis quiser tirar ela do Stage eu posso fazer kit reset E aí o nome do arquivo aí você vê que tira aquela mudança que eu fiz do Stage mas ele não altera o diretório de trabalho ou seja essa modificação que eu fiz aqui olha ela se mantém essa modificação tá feita por exemplo se eu fizer uma alteração agora olha botar um dois aqui no final e se eu quiser restaurar o diretório ao invés do Reset eu posso colocar um restore Ó lá ele alterou e Manteve ali o arquivo no Stage então toda vez que a gente fizer uma mudança e falou assim Ah não eu tô com esse arquivo no Stage e eu quero voltar ess essa versão Eu uso o restore o reset atua tanto no working directory e Stage e também no Head para não complicar demais por enquanto vimos somente ele atuando no Stage Mas é possível por exemplo depois que um comit é feito recetar a versão de um arquivo no R voltando ele no no state vamos ver então um pouquinho mais a fundo o Git status ele mostra ainda que a gente está na bran m a gente vai explicar o que que é Brand daqui a pouco não existe comits ainda exp vamos explicar e a gente já já tem aqui no Stage esses dois arquivos e nesse caso aqui olha o index HTML tá só no diretório de trabalho então é mais ou menos isso que ele mostra pra gente entender o que que a gente precisa fazer para versionar os nossos códigos na próxima vez que a gente tiver sendo modificando os arquivos ó vamos adicionar novamente o index ao Stage E aí eu vou fazer uma outra mudança eu vou colocar como se fosse aqui um rodapé tá um footer E aí ó desenvolvido por código fonte TV se eu quiser ver a diferença agora do Stage pro working dear posso colocar Git dif agora é mais interessante ver esse tipo de mudança através do editor né Por aqui não fica tão legal é porque nesse caso é a a modificação foi feita só em em um arquivo né Se eu colocar eh Git dif index. html.

gz título e fizer um dif Agora ele já vai mostrar que o título foi removido depois desse vai e volta no Stage agora é hora de confirmar as mudanças e criar um Comet ele nada mais é que uma fotografia do estado dos arquivos no repositório em um determinado momento cada Comet contém alterações nos arquivos identificador único que é o hash metadados para saber quem foi que fez aquilo e também uma mensagem para identificar o Comet o papel do Comet é fundamental a até para conseguir trabalhar em equipe dessa forma ninguém sobrescreve o trabalho do outro e obviamente cria rastreamento de alterações os comits fornecem um registro detalhado de quem fez o que e quando o que é crucial para entender a evolução do projeto uma vez que a gente tenha os arquivos todos prontinhos agora sim a gente vai comitar Git commit e a gente tem o parâmetro m e a gente precisa colocar uma mensagem uma primeiro Rastro do que que a gente tá fazendo no código como o primeiro comit a gente coloca primeiro comit e aí o que acontece se a gente voltar no status não tem mais nada a área de trabalho tá vazia então não tem mais nada para ser adicionado agora esse trabalho todo né de adicionar faz o Git AD E aí depois você coloca isso pode ser simplificado também se a gente fizer alguma modificação aqui ó vou colocar o ano ó em 2024 agora a gente tem uma mudança né Se eu colocar E se eu quiser fizer só o Comet de disso eu posso colocar Git comit - a- M menos a vai justamente já adicionar esse arquivo no Stage ou todos os arquivos que forem precisos e depois vai fazer o comit Então já elimina um comando aí no meio do caminho né mas você tem que prestar atenção nisso também porque pode ser que você tenha modificado algum outro arquivo que não tem a ver com o Comet que acaba entrando no Comet então isso tem tem que ser feito com muita atenção alteração futter bom acabamos de fazer o tudo lindo maravilhoso mas sei lá erramos o ano estamos em 2030 não 2024 e a gente quer ajustar o último Comet que foi feito tem criar tem criar um novo então a gente faz uma mudança colocamos aqui ó um Git AD E aí a gente faz um Git comit a gente usa um Amend E aí coloca a mensagem Lembrando que isso só vale pro último comit tá então é aquele desespero de nossa errei fiz besteira ali quero ajustar um pontinho atualizado E aí se a gente for aqui no status a gente vai ver tá tudo limpo novamente se a gente faz uma mudança novamente ah não é 2023 e a gente tem agora uma mudança para fazer e a gente coloca esse arquivo lá no Stage a gente consegue ver a diferença do último comit que a gente fez pro arquivo que está no Stage então a gente pode fazer um gitf coloca Stage tá então ele vai mostrar justamente Olha que no Stage atualmente tá o 2030 e o último comets foi feito com o 2023 no Stage e o último Comet foi feito com 2030 existem inclusive boas práticas para criar mensagens de Comet Pois é ela que Dá pistas aí em um primeiro momento sobre Quais mudanças foram feitas no repositório então usar somente coisas como Fix e update não é recomendável geralmente se usa essas palavras em inglês iniciando a mensagem né como AD Fix ou Change e complementando o que foi feito aliás esse tema gera até um vídeo próprio né se vocês quiserem é só pedir aqui nos comentários e para conseguir ver todas as mudanças feitas É preciso conhecer o log e o histórico pelo terminal Existem algumas formas interessantes de visualizar isso mas nós recomendamos nesse caso usar um editor ou o seu ideia Favorito Pois é visualizar a diferença em arquivos no terminal é um pouco mais complexo mas vai de gosto né de qualquer forma é importante entender o conceito no terminal primeiro e pra gente ver essa estrutura do nosso repositório a gente tem que usar Git log e a gente consegue ver de baixo para cima né a ordem dos comets ó o primeiro Comet e depois vem o texto do footer atualizado Além disso com um hash do Comet tá um hash grande aqui e mostra ó Qual é a range né que a gente tá utilizando com esse comando a gente consegue ver muita coisa se tiver muito Comet por exemplo a gente tem aqui um repositório que tem um monte de Comet que é a nossa pesquisa salarial Se eu colocar por exemplo Git log você vê que tem muita informação ó e se eu quiser ver por exemplo os últimos três comets eu posso muito bem colocar aqui ó traço três então ele vai mostrar só os últimos três uma outra forma interessante da gente ver tudo numa linha só ele omitindo essas informações completas né então eu posso colocar Git log One Line simplifica bastante mas a gente consegue também colocar uma quantidade aqui ó os últimos cinco dá para fazer e essa junção de parâmetros também uma outra forma legal é usar o graph que aí ele já mostra como tão está a Organização das brands a gente pode filtrar também por autor a gente bota Git log traço traço o autor E aí vem aqui ó com igual e o nome do autor ele lista também dá para fazer por exemplo com hum data usando aqui ó Before e aí a gente usa no formato y y y mês e ano se a gente quiser por exemplo ver por pasta também dá aqui a gente tem uma pasta no no repositório chamado data então a gente consegue ver todas as mudanças feitas nessa pasta específica mas existe ainda uma versão mais curta do log por sinal short log é um ótimo nome pro comando short aqui nesse caso ele mostra os autores tá vendo e a quantidade de comets de cada autores e aí e vai colocando ele na ordem né se a gente quiser ver só a quantidade por autor você pode colocar ainda um SN ó e aí sim ele deixa mais curto ainda agora uma coisa interessante é um outro tipo de log que é o Git hef log Esse é um log das ações que a gente faz dentro do repositório não necessariamente as mudanças e os comments nesse caso por exemplo é eu tenho só quatro mudanças aqui porque recentemente eu mudei de computador E aí eu puxei novamente o repositório pra minha máquina então eu fiz um clone depois eu fiz um checkout criando aí uma Branch pra Dev e uma outra Branch de Dev pra versão 2004 2024 da nossa pesquisa muitas ferramentas já implementam esses filtros Então não precisa ficar decorando tudo vamos ver no vs code Como podemos olhar os logs eu tô usando aqui o vs code e eu tenho uma extensão chamada Git graph que é justamente o comando ali o parâmetro que a gente usa no Git né então esse repositório ele tem bastante pastas arquivos tem um histórico grande então se aqui no vs code quando a gente vem em controle de versão ele abre aqui uma opção olha pra gente visualizar as branchs todos os comets aqui e tudo que a gente fez ó então a gente consegue ver realmente um histórico de uma forma muito melhor né fica mais organizado né e visualmente realmente fica mais simples de entender o importante é saber que existe assim você não fica perdido para encontrar algo que foi feito há um tempo e consegue que Comparar as versões rapidamente até agora não explicamos um conceito super importante no Git branchs elas são justamente ramificações em o nosso repositório imagina o Brant como um caminho alternativo pro desenvolvimento quando você cria um Brant no Git está essencialmente criando um ambiente onde pode fazer alterações sem afetar o Brand principal isso é como ter uma cópia paralela do seu código na qual você pode trabalhar independentemente nessa imagem temos os círculos representando os comets veja que a linha principal é o Brand principal que geralmente chamamos de Main ou master entre um cmet e outro na linha do tempo do repositório podemos criar um novo Brand e eles podem ter seus próprios comets que podem ser incorporados depois em outro Brand Existem várias formas de trabalhar com branchs e pode ficar realmente complexo nessa imagem nós temos vários brands Main release develop e feature Mas calma viu a ideia por aqui pelo menos por enquanto não é deixar nada muito complexo imagina então que um Brand É como se você fizesse uma cópia completa do seu repositório inteiro para uma outra pasta para você Testar algo sem estragar o que já está funcionando com um novo Brand é possível criar quantas ramificações possíveis e depois voltar sem problemas aliás eles servem justamente para fazer mudanças e uma vez que você tá satisfeito com elas você pode mescla-se o código principal é justamente esse recurso que permite um desenvolvimento mais organizado e seguro especialmente em equipes quando a gente criou o nosso repositório automaticamente já vem uma Brand aqui chamada Main Então se a gente coloca Git Brand ele vai mostrar Justamente a Brand que a gente tem criada e esse asterístico mostra a Brand que tá aqui em uso né para criar uma nova É muito fácil Git Branch geralmente a gente cria nomes dos mais diversos aí né chamado feature eh Fix então Toda vez que você vai corrigir um problema vai criar uma feature nova a gente acaba criando uma bran nova também mas isso depende muito da Estratégia né Eu geralmente gosto de criar uma Branch chamada Dev E aí eu faço todo o desenvolvimento por ali então Git bran deve ele já cria uma uma Branch nova a gente pode até escluir ela aqui que é o menos D deve tá e uma outra forma de se criar é fazer faz o checkout e criar aqui com o Men B de de brand o nome da Brand que a gente quer e O interessante é que nesse caso ele cria e já vai automaticamente para essa Brand então o checkout serve para isso pra gente navegar entre as brands se a gente fizer agora o Git Brand a gente vê que agora são duas brands e a gente tem ali a o asterisco no Dev que é a Brand que a gente vai utilizar se por acaso você escreveu errado o nome da sua bran Você pode muito bem colocar aqui Git Branch Men M que seria o que Valente ao move né E aí você coloca um nome novo por exemplo Então em vez de Dev Pode ser develop ou até feature mesmo né se a gente quiser ver por exemplo o log de uma Branch específica a gente consegue se eu quiser ver o o log da Main ela vai vir aqui se eu quiser ver o log da developer vai ser igualzinho né porque acabei de criar ela a partir da M Vamos fazer uma mudança pra gente ver isso acontecendo vamos adicionar por exemplo aqui olha o link do CSS eu esqueci e o do JavaScript que aqui mesmo no no vs code ele já mostra qual é a Brand que a gente tá usando no momento e volto aqui vamos fazer um Git comit Men a men m para agilizar E aí é adiciona assets e é legal que dá pra gente ver a diferença agora entre uma Branch e outra né Se eu colocar Git dif E aí eu coloco por exemplo develop e a Main ele mostra justamente qual é a diferença dessas duas brands a base dos BR é essa aí pratique bastante na hora que você entender bem como trabalhar com eles você estará bem próximo de dominar o Git existem muitas abordagens interessantes pro uso dos branchs como o gitflow por exemplo lembre-se de que os branchs devem ser usados para separar diferentes linhas de desenvolvimento e que é uma boa prática mantê-los atualizados com o Brand principal regularmente para evitar conflitos complexos durante a mesclagem a grande sacada do Git é a possibilidade de trabalhar com o sincronismo de repositório de forma remota então é possível enviar todos os comets que você fez na sua máquina para um servidor E isso também pode ser feito por vários outros desenvolvedores ao mesmo tempo óbvio que podem existir conflitos de alterações em arquivos por isso é ainda mais importante trabalhar com códigos desacoplados em funções então no Git Você tem todo o seu ambiente de desenvolvimento no seu próprio computador e que posteriormente pode ser agregado O que chamamos de mergado né ao repositório remoto alguns exemplos mais conhecidos de plataformas para criação de repositórios remotos Provavelmente você já conhecem ó github bitbucket gitlab ou mesmo o Git que é a possibilidade de criar o seu Git na nuvem Como a gente mostrou em um vídeo que a gente vai deixar o Card aqui para você vamos ver então como funciona esse tal de remote no github para utilizar um repositório remoto a gente pode vir aqui no github ele já mostra né o comando ó Git remote AD e bota o o nome que geralmente se chama Orange mesmo e aqui ele coloca a URL né nesse caso aqui não é nem https como a gente usou antes né é o próprio Git com aqui git@github. com a gente copia aqui esse comando ele já adiciona pra gente se eu colocar Git remote Men V eu consigo ver justamente o nome da Brand que a gente usa para acessar esse repositório remoto e pra gente enviar as nossas mudanças pro repositório remoto a gente usa o Git Push a gente pode usar aqui o parâmetro menos u então ele vai do orin pro Main se a gente der um refresh agora ó o código já tá aqui e a gente consegue ver também os comits ó que foram feitos com as descrições e nesse caso veio só a Brant Main porque a gente especificou aqui é o push só na Brant Main se a gente quiser remover também é muito fácil Git remote remove Orange tá não tem problema nenhum remover e pode remover adicionar Sem problema nenhum aí vamos supor que você faça uma mudança num outro computador ou uma outra pessoa faça uma mudança nesse caso aqui a gente vai só adicionar um RM aqui nesse repositório ó fiz duas atualizações E aí a gente precisa trazer isso né pro nosso repositório local e aí como é que eu faço é o p Se eu colocar aqui ó Git Orange M el sincroniza todas as mudanças ele diz aqui quais são as modificações e o meu repositório local já está atualizado Se eu olhar aqui já tem o ridm aqui também então eu excluí aqui a pasta onde a gente estava utilizando e a gente pode fazer um clone justamente do nosso repositório uma vez que a gente já tenha tudo atualizado remoto pode remover local recriar não tem problema nenhum tá tudo lá ó Git log tudo lá mas um outro comando legal é o Git remote show então a gente coloca o nome é do Origin a gente consegue ver qual é o o RL que a gente utiliza né Qual é a as brands que eles estão trando então tem mais informações sobre o Remote se por acaso a gente precisar trocar só o RL do remote vamos supor que modificou também dá então basta você colocar o set URL URL coloca aqui o Orange e a nova URL aqui né do seu do seu repositório em projetos colaborativos é uma boa prática fazer o Git antes de começar a trabalhar e novamente antes de fazer o Git push para garantir que você está sincronizado com as últimas mudanças do repositório lembre-se de que ao trabalhar com repositórios remotos no github ou em qualquer outro serviço de hospedagem Git é crucial entender a dinâmica de pull push fet e o clone para manter seu trabalho local e remoto sincronizados e evitar os conflitos agora para atualizar o seu trabalho em outros branches com o Branch principal é preciso conhecer bem o funcionamento dos Comandos merge e rebase existem outros relacionados também como o fat que são fundamentais para gerenciar e atualizar o trabalho em repositórios Git de nada adiantaria esse trabalho todo se não houvesse uma forma de unir tudo e é aí que está o desafio e onde podem realmente acontecer conflitos agora a gente vai começar a trabalhar com outras brands se eu estou aqui com a Brand M Eu quero ir para uma Branch nova a gente já viu né para criar uma B Branch chamada develop essa Branch a gente a gente já tem né vamos ver ainda não vamos criar novamente a gente clonou novamente o repositório né vou chamar ela de Dev tá E aí vamos supor que a gente esteja desenvolvendo ali algumas mudanças no nosso código a gente pode colocar um outro parágrafo aqui por [Música] exemplo pode voltar ali com o CSS e o JavaScript que saíram Ah é posso fazer aqui uma outra função por exemplo olha E aí a gente pode criar e por exemplo um novos comets né então eu vou colocar aqui tipo atualizações na interface E aí eu posso fazer por exemplo Ah mais um update aqui no H2 que eu esqueci posso colocar aqui ó melhorias no CSS Ou posso ser mais específica né melhorias no H2 Então a gente tem todas essas mudanças a gente pode ver que que tá tudo comit pra gente olhar o log do Dev a gente vai ver que tem esses dois aqui dois comets novos se a gente colocar no Main esses comets não estão lá né E aí como é que a gente faz a gente para unir essas mudanças que a gente fez é no Dev pra m a gente cria um novo Comet é que é especial é um Comet de merge para fazer isso a gente vem aqui e faz um checkout na nossa M então a gente pode vir aqui agora colocar só um merge Dev você vê que não teve conflito ou seja não teve nenhuma linha ali em algum arquivo que teve uma mudança que ele achasse que olha essa mudança aqui eu não posso sobrescrever outra então ele simplesmente adicionou todas essas mudanças no próprio Main Então agora você vê que o Main já está atualizado se fosse o caso de ter algum conflito a gente teria que tratar isso no editor e depois a gente continuar se você eh tiver num conflito você não quero cancelar tudo você pode colocar um abort aí ele sai fora ou você vai no editor faz as mudanças se o seu editor tiver uma integração já no caso vs code tem você pode completar esse merge dentro do editor e também aqui no terminal fazendo a alteração e depois colocando o continue Ou seja é preciso realmente resolver manualmente todos os conflitos que foram encontrados durante o merch se a gente olhar o gráfico do nosso projeto a gente vê que estão todos aqui na mesma no mesma linha no mesmo histórico né e a gente só vai fazendo o merge todo certinho mas existe o caso de fazer o rebase Olha só como que fica na prática a diferença do merge pro rebase enquanto o merge cria um novo Comet a partir da união de outra Brand o rebase move o histórico de comets da Bran de origem PR Bran de destino nesse caso amé vamos supor que a gente vai desenvolver uma nova feature pro nosso projeto então eu vou criar uma bran nova chamada feature né nova feature E aí nesse caso essa nova feature nada mais é que um um botão aqui no meu código [Música] E aí eu percebi que tem uma mudança aqui que eu quero fazer agora a minha página tá em português então eu preciso resolver isso então eu posso adicionar aqui novamente e fazer mais um [Música] Comet mas perceba que se a gente olhar o gráfico a gente vai ver que a gente tá na nova feature e ele tá seguindo exatamente a mesma da Main vamos supor que alguém fez alguma alteração ou foi feita alguma alteração remotamente na Branch Main isso que é importante porque antes da gente fazer merge e rebase a gente tem sempre que atualizar a Main para ela não ficar desatualizado Então se a gente voltar aqui por exemplo para m vamos supor que alguém criou uma função nova tá que vai ser escolher curso se a gente olhar agora o gráfico a gente vai ver que existe a Main que é a atual que a gente tá usando e a nova feature que tá lá só que a a Main ela tá já à frente da nova feature então o que que o rebase vai fazer ele vai pegar esse histórico aqui dessa nova feature e ele vai jogar para cá ele vai mudar a base dele pra última versão da Main então eu vou fazer isso aqui no próprio terminal do vs code pra gente observar essa mudança o Git checkout nova feature E aí eu faço o Git rebase Main Então dessa forma eu vou atualizar a a nova feature com a última e com a última Comet da M como não tem também nenhum conflito Ele autorizou automaticamente Se existisse um conflito ele iria mostrar agora a gente pode jogar a nova feature para dentro da da Main isso vai fazer com que ele esteja alinhado ali com o histórico para fazer isso a gente faz ao contrário a gente faz o Git checkout M Vou apagar aqui E o Git rebase nova feature Observe aqui o que que vai acontecer ó veja que agora a m tá toda atualizada ó com a última versão ó com um novo botão e com a correção da língua da página então a gente tá na bran Main e a gente tem aqui ó tá atualizado aqui e tem também o botão e se a gente olhar o histórico não foi criada uma bran nova para isso né como aconteceria no caso do merge né foi que a gente fez aqui né no Dev E aí por exemplo outras opções né como ele leva o histórico todo é dos comets a gente pode fazer o rebase só é de alguns comets Só se eu quiser fazer o rebase aí nesse caso aqui é um rebase traço I de interativo e eu coloco aqui head por exemplo um Comet ou dois comets ou três né Quantos você quiser porque pode ser que durante o desenvolvimento você Gere vários comets né então você não quer levar todos ou pelo menos o histórico de todos mas você quer levar alguns por exemplo três últimos ali no caso então quando a gente faz isso ele abre um arquivo de texto com o o ID dos comets né da hash dos comets que você quer levar você confirma fecha o arquivo e aí o o o próprio Git faz essa modificação E aí da mesma forma se tiver conflito da mesma forma com o merge a gente tem a opção do abort ou o continue né então toda vez que tiver esse tipo de conflito a gente tem que tratar manualmente no editor e aí a gente vê o que que sai e o que que entra Principalmente quando tá na mesma linha de código o rebase é uma alternativa ao merge para integrar mudanças de um Brand a outro a diferença entre o merge e o rebase é que o merge preserva o histórico completo e a ordem original dos comits o rebase cria um histórico linear que pode ser útil para projetos que preferem um histórico mais limpo então Tenha prudência com rebase e dobre a atenção ao usar o rebase em branchs públicos e ou compartilhados pois ele altera o histórico dos comites chegou a vez das tags que são os rótulos elas no Git são utilizadas para marcar pontos específicos no histórico do repositório geralmente para identificar versões de lançamento ao contrário dos branchs que são mutáveis as tags são fixas significando que uma vez criadas elas não mudam existem dois tipos principais de tags no Git leves e anotadas a tag leve é geralmente um Comet ela é um ponteiro para um Comet específico não contém informações adicionais como autor da tag mensagens ou data já a tag anotada é mais detalhada e contém metadados como o nome do autor data e uma mensagem É recomendada para marcar lançamentos porque permite o uso do GPG para assinar e verificar a tag essas assinaturas GPG são muito utilizadas em gerenciadores de pacotes do próprio Linux e garantem a integridade dos arquivos quando são baixados por exemplo para criar rótulo é muito fácil né então Git tag e o nome da tag então a gente pode colocar aqui versão 2024 Então se a gente colocar Git tag a gente consegue ver todas as tags que tem lá né se a gente for ver por exemplo os histórico tag se a gente bota um online ou outro Ele marca também ó a bran que a gente tá e a tag que tá marcada ali no último Comet para remover é moleza também ó Git tag menos D E aí a tag que a gente não quer mais faltou V Ah é faltou aqui então tag Teoricamente não não faz nenhuma tipo de alteração grave assim é realmente uma marcação agora essa Que Nós criamos foi a tag leve tem também a tag anotada então a gente usa um parâmetro menos a para usar justamente o nome da da tag que a gente quer e a gente pode associar a uma mensagem né então por exemplo a versão 2024 eh do minicurso pra gente olhar a gente pode ver aqui eh a gente pode usar Git show inclusive o nome da tag que a gente quer e ele vai direto eh nas mudanças que foram feitas né Eh nessa tag dá para ver as últimas modificações e ela fica marcada aqui também ó na tag assinada a gente tem que ter um Men s ao invés de Men A e coloca aqui o nome da tag né Pode ser aqui 1. 1 e bota uma mensagem também aí nesse caso precisa estar configurado no seu Git como vai ser feita essa assinatura de arquivo né então é importante ter isso configurado antes Se você quiser enviar né uma tag específica pro repositório remoto você pode fazer isso também usando o push E aí o nome da tag então fica fácil também ao invés de usar um um nome de uma bran você enviar esse nome da tag ele já vai enviando todas as modificações aí aqui no github olha como é que fica Ele marca aqui como uma tag e já dá para ver ó el como como se fosse né um Comet também se você quiser remover também dá para remover através localmente lá no seu repositório né de origem localmente mas no repositório remoto né então Fi besteira não era para ter enviado isso usa o delete E aí ele remove vamos ver se removeu mesmo removeu aqui já tem zero tags Relembrando então alguns dos motivos para usar as tags para versões de lançamento por exemplo marcar um Comet com a tag v1.

0 ou v2.