Masterclass de Git e GitHub — acelere sua jornada para o Git!

1. Vídeo de introdução: Bem-vindo a este curso sobre Git e GitHub. Aqui estão algumas das razões pelas quais você deve aprender o Git e o GitHub. Mais de $83 milhões por cento em todo o mundo usam o Get up. 90% das empresas financiadas pela Fortune usam o GitHub. Mais de 200 milhões de repositórios são projetos que residem atualmente no GitHub. O Github é um componente essencial da sua jornada de DevOps. Na verdade, se você quiser buscar o DevOps Catia, GitHub é um ponto de partida. Você não está chegando a lugar nenhum, a menos que aprenda GitHub. Github também é a plataforma de hospedagem de código mais popular em comparação com seus concorrentes, como Bitbucket ou GitLab, get é o sistema de controle de versão mais popular que já existiu. É quase uma habilidade imprescindível para qualquer profissional de TI. E eu acho que você já sabe disso. Aqui estão os objetivos deste curso. Vou te ensinar tudo o que você precisa saber sobre o Git e o GitHub. Eu o uso desde 2014 e até tive experiência em gerenciar equipes e cumprir os prazos do projeto. Eu ajustei o plano de estudos de acordo. E você não precisa se referir a outros livros ou outros cursos. Você aprenderá tudo o que precisa neste curso sozinho e não precisa ir. Qualquer coisa além disso. Faça você se sentir confiante para lidar com qualquer tarefa de projeto relacionada ao Git e ao GitHub. Ensine você a contribuir com projetos de código aberto e deixe-o confiante com entrevistas. Mas por que você deveria aprender com este curso? Aldi, tópicos importantes e essenciais são abordados nos primeiros capítulos. E todos os tópicos que não são essenciais ou discutidos posteriormente no curso. Só estamos assistindo por seis a dez capítulos. Você começará a se sentir confiante para começar a assumir a tarefa mais tarde para se levantar. Dito isso, eu recomendo fortemente que você assista todo o curso. Para aprender todo o assunto. Eu combino vários tópicos relacionados na mesma palestra para economizar seu precioso tempo. Se faz sentido para mim combinar vários tópicos relacionados e ensiná-los juntos, eu sempre faço isso. Não só para economizar seu tempo, mas também para ensinar de forma mais eficaz. Vou te ensinar esse objeto com cenários, casos de uso e fluxos de trabalho do mundo real . Eu mesmo lidei com alguns dos desafios mais difíceis do projeto. E eu certamente posso usar essa experiência para falar sobre alguns dos cenários do mundo real onde você pode aplicar todos esses conceitos. Tenho a capacidade única de ensinar conceitos muito complexos de maneira fácil de entender. Você entenderá isso sozinho depois de progredir neste curso. Também tenho expectativas sobre quem está assistindo a este curso. Esqueça o que você já sabe e comece do zero. Se você já sabe algo sobre Git e GitHub ou qualquer assunto relacionado, eu quero que você simplesmente apague tudo da sua mente e comece com uma mente limpa. Caso contrário, você poderá ouvir algumas terminologias conflitantes, que podem começar a confundi-lo. Dedicação e compromisso para aprender o interassunto estavam vivendo no mundo das distrações. A menos que você se esforce para se manter comprometido e dedicado a aprender todo o assunto, você não está realmente aprendendo nada. Pratique o que eu ensino. Praticar pela primeira vez equivale a dez vezes de leitura definida por alguém em algum lugar. Mas faz todo o sentido. Você deveria tentar praticar o que eu ensino. Caso contrário, você pode perder o controle do assunto e ficar confuso. Mantenha o foco em um curso, quer você faça este curso ou algum outro curso, conclua-o totalmente e, em seguida mude para outra fonte de informação, se desejar. Mas não misture as coisas, o que novamente criará muita confusão. Dedique apenas uma hora todos os dias sem distrações. É melhor aprender por uma hora com foco total do que aprender por oito horas com um foco não tão bom. Tenha isso em mente. Em seguida, começaremos a entender o que é get Github, o que é sistema de controle de versão, etc., com exemplos do mundo real? E essa é uma ótima maneira de começar nosso curso. Vejo você em seguida. 2. 0101 Necessidade de sistema de controle de versão e Git Parte 1: Por que precisamos do sistema de controle de versão? Conheça o Sr. Bob, que é consultor de investimentos. E devido a todo o trabalho incrível que ele está fazendo, sua base de clientes aumentou significativamente ao longo do tempo. E assim ele vê a necessidade de ter seu próprio site pessoal. Então, Bob imaginou um site próprio. E Bob sendo um cara não técnico, ele pensou em receber ajuda de um freelancer para fazer o trabalho. Então ele conheceu o remetente que é freelance ou inexplicou tudo o que está esperando em seu site e deu o prazo como 24 de fevereiro, que por acaso é o aniversário dele está sob um e comecei a trabalhar no projeto. Insights sobre esses computadores. Lá havia criado uma pasta chamada aplicativo de investimento, dentro da qual ele criou todos esses arquivos que farão esse site. Depois de alguns dias de folga, cylinder finalmente terminou de trabalhar na criação do site. Ele testou. Ele também o hospedou em um provedor de hospedagem ou em um provedor de serviços em nuvem. Deus, o aplicativo está funcionando e o mostrou ao Bob. Bob ficou bastante impressionado com o trabalho feito por sunder. E agora ele decidiu adicionar mais alguns recursos em seu site. E você recebe o prazo como 20 de fevereiro. Dois bens mais cedo, mais uma vez, aceitaram o acordo e começaram a usar esses recursos adicionais. E mais uma vez, Cinder adicionou todos esses recursos, hospedou-o no provedor de hospedagem, colocou o site em funcionamento e o mostrou a Bob. Mas desta vez, porém, Bob não ficou completamente satisfeito com o trabalho. Embora os recursos mais recentes tenham sido introduzidos após 24 de fevereiro, estamos trabalhando bem. Os recursos que estavam funcionando anteriormente parecem ter quebrado ou não estão funcionando conforme o esperado. Então Bob explicou as mesmas duas cinzas e pediu a ele para desfazer todas as novas mudanças e trazer de volta o aplicativo para o que era em 24 de fevereiro. Para isso em breve, eles são aceitos com hesitação. Mas, infelizmente, para Cinder, não será uma tarefa fácil desfazer todas essas alterações porque há muitos códigos novos introduzidos após 24 de fevereiro, e o código se espalhou em vários arquivos. É muito difícil para o remetente se lembrar de cada linha de código que foi introduzida e desfazer todas essas alterações. No entanto, desde aquele que aceitou o negócio, para manter o cliente feliz, depois de muitas noites sem dormir e depois de muita frustração e muito centro de testes finalmente conseguiu o trabalho feito. No entanto, desta vez, no meio do prazo de Bob, e Bob estava se perguntando por que demorou menos de duas semanas apenas para desfazer as mudanças. Bem, ele levou apenas alguns dias para criar o site inteiro. Isso resultou em Bob não ficar satisfeito e logo, logo começou a ver tipos semelhantes de problemas com alguns de seus outros clientes também. Eles estavam reclamando que alguns dos recursos não estavam funcionando conforme o esperado, o que havia funcionado anteriormente. E então eles queriam consertá-los ou querem voltar para as versões anteriores de seus aplicativos da web que estão funcionando bem. Então, Sunder pensou nisso e finalmente teve uma ideia genial, que de alguma forma resolvem esse problema. Falaremos sobre isso daqui a pouco. 3. 0102 Necessidade de sistema de controle de versão e Git Parte 2: Então, o que está lá começou a notar é que ele não tinha sites de clientes do Office de backup. Se você tivesse um backup de seus sites, ele terá a oportunidade voltar para a versão de trabalho anterior do site ou pelo menos n mentiras o problema comparando uma versão com a outra. Cylinder teve uma ideia brilhante para resolver esse problema. O que você começou a fazer agora é, por exemplo , considerar o aplicativo de investimento o qual estávamos falando. Cinder cria uma pasta chamada app de investimento V1 e 14 de março, que é a data em que este projeto foi entregue ao cliente. E então suponha que Bob pediu a ele para apresentar alguns novos recursos. Esse cilindro de tempo não fará nenhuma alteração nessa parte do projeto. Em vez disso, vai fazer uma cópia desse projeto, nomeá-lo como V2 e apresentar todos os novos recursos. E da mesma forma, se Bob pedisse a alguns lá para adicionar ainda mais recursos, ele vai fazer uma cópia da versão mais recente de seu projeto, nomeá-lo como V3, por exemplo. E então faça todas as mudanças necessárias, e assim por diante. Então, toda vez que ele introduziu um novo recurso ou introduziu um grande pedaço de código, é simplesmente copiar a pasta ou o projeto e fazer as alterações necessárias. Desta vez. Novamente, vamos assumir o mesmo caso em que Bob estava reclamando que Washington antes não está funcionando como esperado, e que ele desejava voltar para Washington V3, que estava funcionando bem tão cedo que não tem que tirar o pé deles revertendo todas as mudanças. Ele poderia simplesmente remover a pasta V4 do servidor e substituí-la pela versão de trabalho V3 do site be-bops. Ou se Bob insistiu para corrigir o bug, que pode realmente comparar os arquivos entre v3 e v4 usando um software de comparação como além de comparação, por exemplo, identificar exatamente as mudanças que foram recém-introduzido, analise o problema e corrija o problema. Embora isso tenha resolvido um pouco o problema, repente comecei a perceber que isso está ocupando mais memória do que o necessário. Porque o remetente não está apenas fazendo uma cópia de todos os arquivos que ele modificou, mas também os arquivos que ele nunca tocou. Então, isso vai ocupar muito espaço e está se tornando muito difícil para um similar gerenciar. Então, de repente, surgiu uma ideia muito melhor, que é criar versões dos arquivos dentro do projeto. O que quero dizer com isso? Então, suponha que você mais uma vez tenha um projeto como esse com todos esses arquivos. Agora é claro que neste caso eu os nomeei como HTML, mas isso poderia ser qualquer arquivo, isso poderia ser um arquivo de imagem, arquivo CSS, arquivo JavaScript, arquivo java, o que quer que seja. Para o bem deste exemplo, suponha que temos todos esses arquivos. Agora, suponha que o centro esteja introduzindo um novo recurso que tem algo a ver com o arquivo B e C. Então, em vez de criar uma cópia toda a pasta que fará uma cópia da versão mais recente desses dois arquivos. Isso fará uma cópia do arquivo B e do arquivo, veja, introduza todo o código necessário para o recurso um. E se você quiser introduzir outro recurso, e desta vez assumir que as alterações precisam ir e arquivar o arquivo, veja que algumas delas simplesmente farão uma cópia das versões mais recentes do arquivo a e arquivo. Veja, por exemplo, neste caso, ele vai fazer uma cópia do arquivo aqui, bem como uma cópia do arquivo C, versão um, que tem a versão mais recente do arquivo C. E então ele vai introduzir o novo recurso nele. Uma vez eu posso supor que Bob pediu sunder para remover completamente o recurso e que desejamos voltar para a versão anterior de seu site ambulante. Adivinha Watson, eles podem simplesmente tirá-lo dos arquivos V2 e manter os arquivos V1 tão simples quanto isso. E se você quiser corrigir o bug em vez disso, ele pode simplesmente comparar o arquivo da versão um com Washington para File e identificar exatamente o que está dando errado usando um software de comparação como Beyond Compare. No entanto, Watson eles começaram a notar que mesmo isso não é viável porque está se tornando incrivelmente complexo gerenciar vários projetos de clientes. Por exemplo, o remetente precisa renomear todos esses arquivos de volta para seus nomes originais antes implantá-los no servidor remoto. E ele também começou a notar que seus arquivos estão sempre aumentando, o que está criando um problema não apenas em termos de organização dos arquivos, mas também está ocupando muito espaço. Neste momento, desde que comecei a perceber que é hora de deixar o software fazer o trabalho por ele. Um software que gerenciará versões como software que rastreará alterações históricas, criará backups e permitirá a reversão de alterações, etc. Essa é a principal razão pela qual alguém em algum lugar teve que vir com o software que fará esse trabalho. E esse é o nascimento do get. Agora, get faz muito mais do que isso. Mas eu não estou falando sobre eles agora porque, neste momento, você não sabe o que é o ramo de colaboração em equipe do GitHub na fusão e coisas assim. Vou preservá-los para as próximas palestras. E tenho certeza de que você também deve estar tendo perguntas como, o que é GitHub ou GitLab, o que é ramificação, etc Bem, você só precisa esperar por isso. Não consigo encaixar tudo em um único vídeo, como pacientes e assistir o resto do curso. E você encontrará respostas para todas as perguntas que possa ter. Mas verdade seja dita. Eu gosto de como a manutenção é uma expressão sorridente o tempo todo. Não importa como sua vida está girando em torno dele. Algo para aprender, não é? O que você acabou de dizer? Não. Não. Só estou dizendo que você tem um ótimo senso de moda. OK. 4. 0103 VCS Como funciona: Vamos ver como o Sistema de Controle de Versão, ou simplesmente o software visio, funciona em um nível muito alto. Mais uma vez, suponha que temos sunder, que é um desenvolvedor freelance, e cylinder tem uma nova cliente, Linda, que é dona de um restaurante, e ela queria ter um site para seu restaurante. Então, para aceitar pedidos on-line de nossos clientes. Você pode dizer, com base no sorriso deles que ele está pronto para assumir o projeto. Mas com base em suas experiências ruins passadas com alguns de seus outros clientes que agora decidiram usar um software VCS para gerenciar o versionamento. Cilindro em seu computador local, cria uma pasta com o nome app restaurante, passa alguns dias e introduz todos os arquivos necessários para criar um site com funcionamento mínimo. O software de vídeo terá seu próprio armazenamento de dados para armazenar todos os dados históricos e backups. Quando digo que o Datastore não precisa necessariamente ser um banco de dados relacional ou alguma forma de software de banco de dados. Pode ser tão simples quanto um sistema de arquivos. Normalmente, vendemos software que costuma usar seu próprio sistema de arquivos para armazenar os backups e dados históricos. À medida que avançamos no curso, você entenderá esse conceito muito melhor. Mas, por enquanto, basta supor que isso seja algum tipo de armazenamento de backup para armazenar o estado do projeto. Agora suponha que o cilindro esteja muito feliz com o progresso que ele fez em seu projeto. Ele tem um site com funcionamento mínimo e testou tudo. Tudo está funcionando muito bem. Por isso, decidiu salvar o estado desse projeto atual. Então, para recuperá-lo quando necessário. Então, ele instruirá o software visio a armazenar o estado atual do projeto, normalmente executando um comando. Depois de executar o comando que vemos que software basicamente faz uma cópia de todos os arquivos e os armazena dentro do armazenamento de dados. Agora, suponha que o remetente tenha um novo requisito para introduzir o recurso um. E suponha que todas essas alterações de código precisariam ir para dentro do arquivo, arquivo bn, veja algumas que fizeram todas essas alterações. Mais uma vez, vai executar o comando para salvar o estado de seu trabalho atual. Mas desta vez, o vizir macio, armazenaremos as informações um pouco diferentes em comparação com a forma como elas são armazenadas anteriormente. É assim que vai ser armazenado. Como nenhuma alteração foi introduzida no arquivo a, o software VCU armazenaria apenas a referência de desfilar a. O que isso significa é que ele terá apenas informações sobre o local onde eles arquivam uma cópia. residindo. E a razão para isso é óbvia. Não queremos fazer uma cópia desnecessária de todos os arquivos que estavam intocados ou não modificados e ocupam esse espaço. , quando se trata dos arquivos B e C, No entanto, quando se trata dos arquivos B e C, introduzimos novas alterações. Mas o software mais fácil não fará uma cópia desses arquivos. Adr. O que vai armazenar é, na verdade, a diferença entre o arquivo modificado e a versão mais recente do mesmo arquivo. E ele armazenará o mesmo no Datastore. Chamamos que cada um desses tem um conjunto ruim. Essencialmente, um conjunto incorreto é a diferença entre o arquivo original e a versão mais recente do mesmo arquivo. E a razão para isso é mais uma vez óbvia. Queremos economizar esse espaço o máximo possível. Da mesma forma, suponha que temos um novo recurso chamado recurso ao qual é introduzido. E o arquivo a e o arquivo B foram modificados. E é assim que o software VCS armazenaria os dados. Portanto, temos conjuntos de PAD para o arquivo a e o arquivo B. E, em seguida, para o arquivo C, vamos armazenar apenas a referência de sua versão anterior. E, da mesma forma, suponha que temos outro recurso. Vamos fazer modificações no arquivo B. E é assim que o software VCO, que armazena as informações, agora assumiu que o cilindro não está satisfeito com a versão do arquivo bruto B e que ele queria voltar para a versão três do arquivo B. Então, ele vai inserir o mesmo no software vizir. O visto mais suave então pegaria a cópia original do arquivo B e aplicaria todos os patches que vieram depois dele até a versão três para compor o arquivo B da versão três e vai devolver para domingo. Ele pode fazer o que quiser com isso. Um ouvinte semelhante também pode escrever o comando instruindo o software a obter a torção do projeto inteiro três, por exemplo, e o software fará exatamente isso. Agora, obviamente, existem muitos softwares vizier disponíveis no mercado. Temos boas Mercurial, SVN, etc. E todos eles diferem ligeiramente em termos de como os dados históricos gerenciados. Mas, em geral, é assim que gerenciam dados históricos. Agora vamos nos aprofundar e entender o que exatamente acontece, o que aconteceu, por quê? Eu não me importo como funciona internamente. Isso não me ajuda com meu trabalho de qualquer maneira. Eu só quero saber como usar o software. Isso faz sentido. Isso faz sentido. Apenas um último vídeo e então começaremos a instalar o portão e sujaremos as mãos com muita prática. Que tal isso? Obrigada. Você é bem-vindo. 5. 0104 DistributedVCS: Vamos falar sobre o sistema de controle de versão distribuído. Linda está bastante feliz com o trabalho feito até domingo e começou a notar um aumento na receita de nossos negócios desde que lançou um site. E devido ao aumento nas demandas dos clientes, ela agora decidiu ter ainda mais recursos em seu site. Ela quer que a segunda abordagem seja fazer o trabalho por ela. Mas desta vez, devido às crescentes demandas de nossos clientes, ela tem um prazo muito curto para assistir. remetente aceitou o acordo, mas alguém está ciente do fato que ele não pode fazer isso sozinho e que ele precisava contratar algumas pessoas em sua equipe, ajudá-lo a entregar o projeto no prazo. Então, Sunder contratou algumas pessoas para conhecer Asia e Luke, que são os novos membros da equipe. O remetente também forneceu eles um MacBook Pro novinho em folha, compartilhou os arquivos do projeto ou o código. Ou talvez ele tenha hospedado retornar um servidor FTP, compartilhou o link e pediu que eles baixassem. E ele também os instruiu a instalar o software no computador local, considerando todos os seus benefícios. Claro, sob tem sua própria inscrição local e seu próprio conjunto de problemas à medida que eles estão progredindo no projeto. Desde que comecei a notar alguns problemas com o uso de um sistema de controle de versão local. Alguns dos problemas que eles estão enfrentando são essas mudanças não históricas de outros membros. Por exemplo, se ele quiser dar uma olhada nas mudanças históricas feitas no arquivo a, ela só poderá dar uma olhada nas mudanças históricas que ela fez, mas ela não tem acesso a dados históricos de outra pessoa, por exemplo, cilindro, porque ele só tem acesso ao seu próprio armazenamento de dados, mas não é assim neste armazenamento de dados. Agora, isso é claramente um problema. A menos que ela tenha acesso a todo o histórico de mudanças, ela não pode efetivamente trabalhar em uma tarefa. Outro problema é que é difícil manter a base de código mais recente. Sempre que alguém faz uma alteração, eles precisam informar a outros desenvolvedores que eles fizeram essa alteração e a necessidade copiar esse código em sua máquina local também. Portanto, para ter a versão mais recente do código em todos os computadores, é claro que isso é praticamente impossível, especialmente quando você tem vários membros da equipe trabalhando em uma única base de código. E as coisas ficariam ainda mais complicadas se duas pessoas trabalhassem exatamente no mesmo arquivo. Outro problema é a ausência de gerenciamento centralizado de funções ou controle de acesso. Por exemplo, suponha que alguém queira restringir Luke de que ele só pode acessar conjunto específico de pastas no projeto, mas não as outras pastas. Bem, com o sistema de controle local de Washington, ele não tem controle sobre isso. O remetente pensou em todos esses problemas que está enfrentando e fez uma pesquisa no Google. E finalmente surgiu o chamado sistema de controle de versão centralizado. Significa simplesmente que desta vez, em vez de ter o armazenamento de dados, bem como o código nas inscrições locais estão nas máquinas locais. Ele estará em um servidor centralizado. E todos escolheriam o código do servidor centralizado, trabalhavam nele e depois o enviavam de volta ao servidor para que outras pessoas pudessem usar seu código. E com isso, podemos nos livrar de todos os problemas que tivemos com sistema de controle de versão local. Mais uma vez, se a esa quiser dar uma olhada em todos os dados históricos de um determinado arquivo, ela terá acesso fácil a ele. Porque desta vez, todos os conjuntos de caminhos são mantidos em um servidor centralizado e todos os desenvolvedores teriam acesso a ele. E com apenas um comando simples, todos seriam capazes de obter o novo código mais recente e começar a trabalhar em cima dele. Então, para evitar conflitos. E o Cinder também pode ter um melhor controle sobre quem pode acessar o quê. Como tudo está hospedado em um servidor centralizado, ele agora pode começar a usar o controle de acesso baseado em função. E ele terá controle sobre quem pode acessar quais pastas do projeto, etc. No entanto, os sistemas centralizados de controle de versão vêm com seu próprio conjunto de problemas. Por exemplo, e se vários forem para um sorteio? Ou se alguém invadir o servidor? E se ele mostrar problemas de conexão? Talvez o Wi-Fi dela não esteja funcionando. Em todos esses casos, os desenvolvedores não podem trabalhar no projeto. Eles também podem correr o risco de perder o código inteiro se não conseguirem gravar o servidor. Considerando todas essas desvantagens oferece sistema de controle de versão centralizado, tive que descobrir uma alternativa. E foi assim que ele se deparou com um sistema de controle de versão distribuído. É basicamente o melhor dos mundos do VCS local e do VCS centralizado, eliminando todas as suas desvantagens. Desta vez com sistema de controle de versão centralizado. Em vez de ter um único depósito como servidor centralizado. Aqui, cada durável terá seu próprio servidor e cada desenvolvedor terá uma cópia de todo o histórico ou versões do código em sua própria máquina local. O que isso significa é que, mesmo que o servidor queira realizar uma tarefa, todos têm sua própria cópia local de todo o código, bem como os dados históricos. E se alguém como a Ásia, o que perder conectividade, talvez por causa de uma conexão Wi-Fi, ela ainda pode progredir porque ela está tendo tudo em seu computador local. Ela pode fazer mudanças. E sempre que a conexão voltar ao normal, ela pode entregar o código para o servidor centralizado para que outros desenvolvedores possam obtê-los e fazer algo com ele. Ou, em caso de perda de dados, cada dólar mais ter um backup de toda a base de código. Assim, eles podem se lembrar de alguns dos exemplos de sistemas de controle de versão centralizados ou subversão CVS ou simplesmente SVN Perforce, ou alguns dos exemplos de sistemas de controle de versão centralizados. Alguns dos exemplos de sistemas de controle de versão distribuídos são Mercurial, Bazaar e Git. O Git é um sistema de controle de versão distribuído. Todos os desenvolvedores precisariam instalar o Git na máquina local. Além disso, também temos o GitHub, que funciona como um servidor centralizado. Acho que ganhamos conhecimento suficiente para começar a trabalhar com o Git. 6. 0105 InstallingGit: Ok, vamos ver como podemos baixar, instalar e configurar, entrar em nossa inscrição local. Agora suponha que sou freelancer e tenho um projeto muito pequeno que sinto que posso andar sozinho. Esqueça a colaboração em equipe, esqueça as várias pessoas envolvidas no projeto. Esqueça o GitHub por enquanto. Vamos apenas manter o foco em conseguir. Então vá ao Google e pesquise por download, acesse o primeiro link, mas verifique se ele pertence ao site. Obtenha hífen SCM. Esse é o site oficial da get. Quando estiver lá, dependendo do sistema operacional que você está usando, clique no link relevante. Agora, no momento em que você estiver visualizando esta página, talvez você veja um layout diferente. Mas você entendeu. Você só precisa clicar no link específico seu sistema operacional. Estou usando o Windows. No meu caso, se você estiver usando o macOS, há um conjunto separado de instruções para o mesmo. Basta segui-los. E durante a instalação, você pode deixar tudo para o padrão e prosseguir com a instalação. E não é necessário que você entenda cada passo durante a instalação. Isso é perfeitamente normal. Caso você tenha algum problema ao instalar nos conjuntos macOS, entre em contato conosco e poderemos ajudá-lo. Mas como estou usando o Windows, vou clicar aqui. Eu basicamente tenho algumas opções. A primeira delas é a versão de instalação do Git e a outra é a versão portátil do Git. Se eu baixar a versão portátil, posso começar a usar o Git sem precisar instalá-lo. E isso pode ser útil, especialmente se eu quiser trabalhar em vários computadores e não quiser instalar o Git em todos os computadores. Posso simplesmente despejar todos esses arquivos em um pen drive ou pen drive e começar a usar o bem em todos esses computadores. Mas eu vou usar o instalador. Estou usando o sistema operacional de 64 bits, então vou clicar nisso. Bem, para usuários de Linux e Mac, talvez você já tenha o Git instalado. Você pode simplesmente verificá-lo executando um comando. Eu vou te mostrar esse comando daqui a pouco. Ou você já pode ter essas bibliotecas, então você só precisa instalá-las. Você pode seguir as instruções de instalação para o mesmo. Então, eu baixei isso. Vamos agora começar o processo de instalação. Se você tem pacientes passando por toda essa licença, eu não tenho muitos pacientes, eu apenas cliquei em Avançar. Agora, ao instalar o Git, você pode se deparar com certas etapas, certos prompts, certas terminologias que não lhe parecem familiares. Está perfeitamente bem. Como regra geral, lembre-se, mantenha tudo seus padrões e prossiga com a instalação. Não é necessário que você entenda cada etapa desse processo de instalação. Desde que eu trabalhei nisso por um longo tempo. Eu entendo o que está sendo perguntado aqui. Mas para você, você não precisa entender tudo. Eu só o guiaria pelas etapas que eu sinto que você seria capaz entender com base no nível de conhecimento que você adquiriu até agora neste curso. Então eu poderia deixar tudo para o padrão. Mas o que esse prompt está basicamente nos perguntando é que ele está nos pedindo para escolher os componentes que queremos instalar. Vamos falar sobre o Git Bash e começar. Na próxima palestra. Você pode simplesmente ignorar e manter o resto dessas coisas nos padrões. Não queremos entrar em muitos detalhes. Não é o que aqui é basicamente pedir que você escolha um software para editar arquivos dot get. Eu instalei o Notepad Plus Plus no meu computador e posso escolher isso. E eu também recomendaria que você usasse o mesmo software. É de código aberto. Você não precisa pagar nada por isso. Baixe o Notepad Plus, Plus, é uma ferramenta incrível. Escolha isso e clique em Avançar. Deixe isso como padrão porque você não sabe o que é uma ramificação neste momento. Portanto, não faz sentido para mim explicar a vocês sobre essa etapa. Então, vamos deixar isso como padrão. Ok, nesta guia está basicamente nos perguntando se vamos usar apenas o Git Bash ou se também vamos usar a linha de comando do Windows? Essa etapa é específica para o Windows. Talvez você não esteja vendo etapas de instalação semelhantes. Esforço para instalar o Git em outro sistema operacional, como Linux ou macOS, você pode estar vendo um conjunto diferente de instruções. Mas, como eu disse, deixe tudo para o padrão e termine a instalação. Mas aqui, se eu escolher essa opção, get realmente adicionará uma variável de caminho nas variáveis de registro do sistema para que possamos começar a usar comandos Git no processador de comandos do Windows. Se você escolher essa opção. No entanto, não vai fazer isso com uma suposição de que só estaria usando o Git Bash. Novamente, vamos falar sobre o Git Bash, fique cinza na próxima palestra. Em seguida, vou deixar isso como padrão. Basicamente. Ele está perguntando se eles querem usar o OpenSSH existente ou se você já o instalou. Você pode simplesmente apontar para isso. Mas vamos usar o OpenSSH que vem junto com o bom. A propósito, abertura que essencialmente permitiria que você se conectasse à máquina remota de maneira segura. Mais sobre isso nas próximas palestras, com certeza. Deixe isso como padrão também. Obviamente, você não entende o que é combate ou esse checkout, então não posso explicar nada sobre isso agora. Deixe-o como padrão. Deixe o padrão. Ok, isso falando sobre git pull. Novamente, isso é muito avançado para você entender. Basta deixar tudo para o padrão. Eu sou britânico ou você pode não estar entendendo todos os passos aqui. Nem tente entender que não é necessário. Vamos explorar tudo nas próximas palestras. É perfeitamente normal. Se você não entende, está tudo bem. Confie em mim. Clique em Avançar. Ative o armazenamento em cache do sistema de arquivos. Sim, queremos, isso melhoraria o desempenho. Também podemos desmarcar isso e clicar em Instalar. Espere um pouco. Tudo bem, eu não quero ler as notas de lançamento. Acabamento da cabeça. Ok, agora instalamos em nossa máquina local. Vamos verificar. Se ele realmente foi instalado. Estou com a janela aberta, processador de comandos do Windows. E, em seguida, digite get. Se você conseguir ver uma saída como essa. Isso significa que o get foi instalado com sucesso. E a razão pela qual podemos executar o comando git a partir do processador de comandos do Windows é porque em algum lugar no meio do processo de instalação, pedimos para incluir a variável path de get in variáveis de inscrição do Windows. Deixe-me mostrar o que quero dizer. Pesquise variáveis de inscrição. Clique em Editar variáveis de registro do sistema. Se você for para o caminho. Aqui você veria o caminho para obter a biblioteca. Então, sempre que você executar o comando, algo assim será executado. Na verdade, o sistema operacional Windows vai dar uma olhada em todas essas partes listadas aqui. E então ele se depara com essa parte em que ele tem o código para fazer algo com o comando GET. E, portanto, somos capazes de ver essa saída. Se você remover isso, não conseguiríamos executar nenhum comando Git do processador de comandos do Windows, a menos que acessássemos explicitamente esse diretório e fizéssemos isso. De qualquer forma, se tudo isso soa confuso, simplesmente ignore, confie em mim, você vai entender tudo nas próximas palestras. 7. 0106 Git CLI vs Git Bash vs Git GUI: Existem basicamente três maneiras de interagir com o Git. Podemos usar get CMD ou Git Bash ou obter GUI ou interface gráfica do usuário. Obtém CMV nada mais é do que o processador de comandos do Windows que usamos para executar comandos git. Na verdade, já tínhamos dado uma olhada em um exemplo do mesmo em nossa palestra anterior, onde estávamos testando a instalação do getting. A outra opção que temos é usar o Git Bash, que é uma ferramenta que instalamos junto com o Git. Git Bash é semelhante ao processador de comandos do Windows, exceto que podemos usar comandos padrão do Linux para interagir com o bem. Isso será útil, especialmente se você estiver vindo do Linux, onde está acostumado a executar comandos do Linux. E agora digamos que você esteja trabalhando no sistema operacional Windows. Você não precisa usar essa curva de aprendizado adicional para entender o comando do Windows para interagir com o Git. Por exemplo, para listar todos os arquivos em uma pasta específica dentro da linha de comando do Windows, use o comando lá. Enquanto no Linux, você usa o comando ls para listar todos os arquivos. Se você estiver usando um Mac ou Linux, ambos vêm com shell Unix. Você não precisa instalar o Git Bash. O Git Bash destina-se apenas ao sistema operacional Windows. Se você não está acostumado com nenhuma dessas ferramentas, então obviamente é sempre melhor escolher o Git Bash em vez de um bom cmd. E a razão é que, se você está acostumado com o Git Bash, você também pode trabalhar no sistema operacional Linux mais tarde, se quiser. A terceira opção que temos é obter GUI ou interface gráfica do usuário. E como o nome sugere, essa ferramenta fornecerá uma interface gráfica do usuário para interagir com o Git. Agora, devo mencionar que o get gooey não tem suporte para todos os recursos que o get tem a oferecer. Podemos fazer mais com o Git Bash ou obter combate CMD para obter glória. Dito isso, uma boa GUI também tem seu próprio papel. Por exemplo, se você quiser dar uma olhada no quadro geral, ou se quiser ter uma visão panorâmica de todas as mudanças históricas, etc. Então você pode achar útil usar a consulta get em comparação para obter esse dinheiro. No entanto, no restante do curso, usaremos o Git Bash, pois essa é a melhor opção. Podemos muito bem explorar o caminho certo em algum momento do curso. Mas vamos nos concentrar principalmente no Git Bash, que também é a escolha popular. 8. 0107 Comandos básicos: Vamos dar uma olhada em alguns dos comandos básicos que podemos executar no Git Bash para interagir com o sistema de arquivos do Windows. Agora, se você tem experiência em Unix ou Linux, provavelmente conhece todos esses comandos. Sinta-se à vontade para pular o vídeo. Você não precisa assistir ao resto da palestra. E para outros, você pode estar se perguntando por que temos esses comandos? Bem, no Windows, criamos pastas. Dê uma olhada no que está dentro dele ou exclua pastas. Fazemos isso graficamente que o Windows nos fornece. No entanto, se você quiser fazer o mesmo a partir do Git Bash, precisamos usar esses comandos porque Git Bash não vem com uma interface gráfica do usuário. Agora você pode estar tendo outra pergunta. Por que precisamos interagir com o sistema de arquivos usando esses comandos quando podemos fazer o mesmo no Windows? Bem, a resposta é, você pode fazer isso de qualquer maneira. Mas se você aprender esses comandos, isso pode ser útil para você no futuro. Por exemplo, se você fosse trabalhar no sistema operacional Linux, você não tem o sistema operacional Windows lá. Você precisa interagir com o sistema de arquivos usando esses comandos. E esses comandos também não são difíceis de aprender. Na verdade, eles são bem autoexplicativos. Por exemplo, temos MKDIR significa make directory. E como o nome sugere, ele o ajudará a criar um diretório ou uma pasta. E então temos CD significa diretório de mudança. Isso ajudará você a mudar de um diretório para outro diretório. E esse é o comando que usamos para navegar dentro do sistema de arquivos. E então temos PWD significa diretório de trabalho atual, que apenas imprimirá a dieta na qual estamos atualmente trabalhando no Git Bash. Se você já se perguntou em qual diretório está trabalhando, esse é o comando a ser executado. E então temos Ls significa lista. E isso apenas listaria todos os arquivos em um diretório específico. Este comando combinado com a opção hífen a, lista todos os arquivos, incluindo os arquivos ocultos. E então, finalmente, temos nossos suportes M para remover. E, como você deve estar adivinhando, isso nos ajudará a excluir uma pasta ou um arquivo. Agora, alguns desses comandos iriam com certas opções. Vamos explorá-los em pouco tempo. Eu criei uma pasta de teste para o bem desta palestra. E é aqui que vamos experimentar com todos esses comandos. Em primeiro lugar, vamos lançar o Git Bash. Você pode iniciar o Git Bash no menu Iniciar ou simplesmente clicar com o botão direito do mouse e clicar em Git Bash aqui, isso iniciaria o Git Bash no diretório atual. Você verá uma tela que se parece com isso. Vamos começar criando uma nova pasta. Então ele recebe o comando que eu preciso usar. É MKDIR significa make directory. E vou fornecer o nome da pasta ou do diretório que eu queria criar. Vamos chamá-lo de meu aplicativo ou qualquer outra coisa. Então, isso criou um novo diretório para garantir que ele realmente criou um diretório. Vamos executar o comando ls para listar todos os arquivos no diretório atual. E com certeza vemos o diretório que acabamos de criar. Também podemos acrescentar uma opção hífen a para listar todos os arquivos, incluindo os arquivos ocultos. Mas, no momento, neste território, não temos nenhum arquivo oculto para mostrar. Mas esse comando será útil no futuro, especialmente quando quisermos explorar o diretório de presentes, que está oculto. Agora vamos entrar no diretório do aplicativo. Como eu faço isso? Porque o comando cd para alterar o diretório. E eu queria mencionar esse diretório, clicar em Enter e atualmente estamos dentro do diretório MyApp. Para ter certeza de que estamos dentro desse diretório. Vamos executar o comando PWD para verificar o diretório de trabalho atual e isso imprimirá meu diretório de aplicativos. Agora vamos para o diretório pai do meu aplicativo. Então, como eu faço isso? Nós fazemos espaço cd, dot dot slash. Se você quiser ir para o diretório dos avós, então você só tem mais uma barra de ponto. E isso resolverá o problema. No entanto, eu só gostaria de ir para o diretório pai. Agora vamos fazer o comando ls para listar todos os arquivos. Agora, digamos que eu queira excluir essa pasta, obtenha o comando, seja RM e o nome da pasta. Mas isso não excluirá a pasta. Bem, isso não exclui a pasta porque esse usuário não tem permissão para fazer isso. Ou essa pasta pode ter arquivos nela. E está nos pedindo para excluir esses arquivos primeiro. Só então isso nos permitirá excluir essa pasta? No entanto, sabemos que essa pasta não tem nenhum arquivo nela. Então, tem que ser a outra razão. Para contornar isso, temos que incluir uma opção junto com o comando RM, que é hífen r, f. R significa recursivo e F significa força. Recursivo significaria que estamos dizendo, não apenas queremos excluir essa pasta, mas também todos os arquivos nela? E esforço significa força. Em outras palavras, queremos forçar a exclusão da pasta, independentemente das permissões. Vou especificar o nome da pasta. E desta vez ele exclui a pasta. Se fizermos ls agora, ele não mostrará mais essa pasta. Então, dedique de cinco a dez minutos e tente experimentar e brincar com esses comandos. Basicamente, tente criar pastas, excluir pastas, dar uma olhada no que está dentro das pastas, etc. 9. 0108 O que é exatamente o Git Commit: Você provavelmente já ouviu falar do git commit, mas o que exatamente é? Vamos dar uma olhada. Imagine que você está jogando um videogame. E suponha que você tenha feito progresso suficiente no jogo que não queira arriscar perder. Você salva o jogo nesse momento dando uma mensagem significativa, continua jogando e progredindo. E mais uma vez, você quer salvar o jogo. E você simplesmente começa dando uma mensagem significativa. E se algo der errado com o seu jogo, basta dar uma olhada em toda a lista de salvamentos que você fez e carregar o jogo em um ponto específico. Agora, você precisa observar que o salvamento aqui não é realmente um backup. É como um instantâneo. Por exemplo, você não pode simplesmente copiar o arquivo salvo e levá-lo para outro sistema onde o mesmo jogo está instalado e ser capaz de carregar o jogo a partir desse ponto salvo. Não é possível. No entanto, se isso for um backup, você fará o backup de todo o jogo. Por exemplo, se o jogo estiver dentro de uma pasta, você simplesmente copiaria a pasta inteira, levaria para outro sistema e iniciaria o jogo onde deseja iniciar. Salvo aqui é essencialmente como um instantâneo, mas não exatamente um backup. Analogia semelhante pode ser explicada com os pontos de restauração do Windows. Você pode criar vários pontos de restauração ao enviar uma mensagem significativa. E se algo der errado com seu sistema, talvez um vírus ou algo assim, eu realmente gostaria que isso não acontecesse. Mas se algo assim acontecer, basta dar uma olhada em toda a lista restaurada depois de criar, escolher uma delas e restaurar o sistema de volta ao seu estado anterior. Assim como você restaurou pontos para Microsoft ou a opção de salvar para um jogo, você tem git commit. Para o seu projeto. Você vai fazer algum progresso em seu projeto. Por exemplo, vamos supor que você tenha feito um blog no recurso um. E então você sente que já fez o suficiente para salvar o projeto ou comprometê-lo. Você faz exatamente isso usando o comando git commit. E então você continua com o projeto. Você trabalha em outro recurso e , em seguida, compromete o projeto com uma mensagem significativa. E se algo der errado com o seu projeto, então get permitirá que você volte ao estado anterior do projeto ou reverta um arquivo específico para suas versões anteriores, etc. então get permitirá que você volte ao estado anterior do projeto ou reverta um arquivo específico para suas versões anteriores, etc. backup em um jogo. O commit do Git não está realmente fazendo um backup de todo o seu projeto, mas sim tirando um instantâneo do seu projeto naquele momento específico. Assim como você criou um projeto com todos esses arquivos. E agora você sente que já fez o suficiente para salvar o projeto ou confirmar todas as alterações no repositório. Agora você não pode simplesmente executar o comando git commit e mencionar todos os arquivos que você quer acessar commit e mencionar . Não funciona dessa forma. Infelizmente, há uma etapa adicional envolvida antes de você entrar. E há uma razão para isso. Por exemplo, você pode ter outros arquivos no projeto que não devem ser confirmados. Você não quer que outros membros da equipe possam acessar esses arquivos. Por exemplo, ele pode ter alguns arquivos gerados automaticamente ou você pode ter certos arquivos que se destinam apenas a serem usados localmente, mas não deveriam estar disponíveis para o mundo exterior. E é aí que temos uma etapa adicional em que você precisa deixar no motor todos os arquivos que você queria rastrear. Atualmente, todos esses arquivos em seu diretório de trabalho não são realmente rastreados pelo Git. Você precisa dizer explicitamente quais são todos os arquivos que você queria rastrear. Você pode fazer isso com o comando git add. Você quer usar este comando git add. E você mencionou todos os arquivos neste caso, vamos mencionar por arquivo de camada, arquivo C e D e executar o comando que essencialmente copiaria todos esses arquivos para a área de teste. E é aí que o get começará a rastrear esses arquivos. Depois de fazer isso, você usará o comando git commit para todas as alterações em um repositório local, ou às vezes denominado como banco de dados de objetos. E esse não é o único caso em que você pode precisar do git add git commit. Vamos dar uma olhada em mais um caso de uso. Imagine que você tem alguns recursos para usar. E você trabalhou simultaneamente em ambos os recursos e presumiu que as alterações do recurso um entraram no arquivo a e no arquivo B. E as alterações do recurso dois foram no arquivo C e D. Agora queremos que esses dois recursos sejam indo para diferentes commits, não em um único comentário. Como fazemos isso? Se não houver o conceito de encenação? E se usássemos o comando git commit, que confirmaria todas essas mudanças, não queremos isso. Então, com o comando git add, primeiro adicionaremos todos os arquivos relacionados ao recurso um. E então cometemos as mudanças com uma mensagem significativa, assim como recebemos uma mensagem significativa ao salvar um jogo. Também vamos fazer o mesmo em gets off comet. Agora, quando você terminar com isso, vamos adicionar os arquivos C e D e confirmar como recurso para. Durante um período de tempo. Vamos manter todos esses comentários em nosso repositório local. E dessa forma, poderemos dar uma olhada em todos os dados históricos, seríamos capazes de recompensar nosso projeto volta ao seu estado anterior. Ou podemos fazer o que o arquivo específico para uma versão específica de sua história passada. Ou podemos querer dar uma olhada na diferença entre a versão atual do arquivo e suas versões anteriores, e assim por diante. Vamos explorar tudo isso nas próximas palestras, com certeza. E, eventualmente, vamos enviar todas essas alterações para um repositório centralizado como o GitHub. E isso é que todos os outros membros da equipe poderiam acessar suas alterações e também todos os seus comentários e dados históricos. No entanto, esse é o tópico de outro capítulo. Também devo mencionar que, quando comecei a usar o Git, entrei em uma comunidade local do GitHub. Agora fiz essa pergunta a eles. Por que precisamos de algumas etapas para confirmar as mudanças? Por que não podemos simplesmente ter um comando que se parece com isso. Vamos mencionar git commit hyphen m. E então você vai dar uma mensagem. E então você vai listar todos os arquivos que você deseja confirmar que podem ser correspondentes ao recurso dois, por exemplo. Bem, eu não recebi nenhuma resposta satisfatória deles. Na verdade, se você falar sobre outros sistemas de controle de versão como Mercurial ou subversivo, eles não têm essa etapa adicional de adicionar os arquivos antes de confirmar. 10. 0109 Iniciando o projeto e explorando pasta de dots: Vamos ver o que significa inicializar um projeto. Para entender isso melhor, vamos supor que eu tenho um contrato de freelancer, enquanto pedi para criar um aplicativo da web para meu cliente. Dentro do meu sistema, criei essa pasta com o nome meu aplicativo, dentro da qual vou apresentar todos os arquivos necessários para criar um aplicativo funcional mínimo em funcionamento. Agora eu poderia criar todos esses arquivos usando a nova opção aqui. Mas, na verdade, vou fazer isso usando o Git Bash apenas para que você se familiarize com todos esses comandos do Linux. E os comandos que eu preciso usar são chamados de toque. E então vou especificar o nome do arquivo. Para simplificar, vou simplesmente chamá-lo de TXT de um ponto. Agora, obviamente, não faz sentido ter um arquivo TXT para escrever o código-fonte. Mas não estamos realmente interessados em criar aplicativos aqui que queremos aprender, entrar, fazer certas suposições. Da mesma forma, vou criar dois rod dxdy. Eu entendi o nome errado. E três pontos dx, dy. Vamos renomear isso para TXT de dois pontos. Então, eu tenho todos esses arquivos criados. Mas atualmente nenhum desses arquivos é gerenciado pelo Git. Por exemplo, se eu fosse executar o comando git commit agora, ele lançaria uma mensagem dizendo que não é um repositório Git ou qualquer diretório pai. Portanto, precisamos informá-lo que ele precisa gerenciar seu projeto. E a maneira como você diz isso é usando um comando git nele significa inicialização. Depois de inicializarmos o projeto, estamos essencialmente pedindo para configurar um escrito, ele precisa ser configurado dentro do nosso projeto para agora começar a gerenciar um projeto. Vou criar versões em que pedirmos. E se você notar, ele criou uma pasta oculta com o nome dot get. É aqui que temos essa área de preparação que falamos anteriormente. E é aqui que temos o banco de dados de objetos que foi falado anteriormente. Caso você não consiga ver essa pasta, será necessário ativar a opção mostrar os arquivos e pastas ocultos. Dentro do Windows, você precisa ir até a guia Exibir, clicar em Opções, clicar em Alterar pasta e opções de pesquisa. E mais uma vez dentro da guia de visualização, você poderá localizar essa opção para ativar ou mostrar os arquivos ocultos. E aqui está. Clique nesta opção que diz mostrar arquivos, pastas e unidades ocultas. Clique em Aplicar e OK, e agora você poderá encontrar essa pasta. Vamos dar uma olhada no que está dentro dele. Agora, obviamente, não vale a pena ir fundo e tentar entender tudo o que está aqui dentro. Exploraremos alguns deles no restante do curso conforme e quando acharmos apropriado. Mas, por enquanto, vou dar uma visão geral do que está dentro dessa pasta. Temos essa pasta de ganchos dentro da qual temos vários scripts. Esses scripts definiriam o que precisa ser feito antes e depois de um evento específico. Por exemplo, já estamos cientes do evento commit. E então temos o script com o nome pre-commit. Como o nome sugere, ele faz algo antes de executar a lógica de confirmação real. Então, execute este script antes de executar a lógica de confirmação. Então, podemos estar tendo coisas como validar a sintaxe, etc. Se você está realmente curioso sobre o que está dentro dos scripts, você pode clicar com o botão direito do mouse e abri-lo com o Notepad Plus, Plus. E basta passar por todos esses comentários e tentar ter uma ideia do que está fazendo. Mas eu não recomendo que você faça isso. Não se confunda. Em seguida, temos a pasta de entrada dentro da qual temos esse arquivo de exclusão. Vamos abri-lo com o Notepad Plus, Plus. Se houver algum arquivo em seu projeto que você não queira considerar, é aqui que você os listaria. Você também pode usar padrões. Por exemplo, você pode dizer star dot log. E agora get ignoraria todos os arquivos com qualquer nome, mas tem a extensão dot log. Só um exemplo. E, a propósito, excluir arquivo é algo que é local para um computador. E tudo o que você adicionar aqui só é aplicável dentro do seu próprio depositante, dentro do seu sistema local. Se você quiser ter exclusões em todos os membros da equipe, então há uma coisa separada para isso chamada gitignore. Falaremos sobre isso nos próximos capítulos. Em seguida, temos a pasta de objetos. É aqui que bons alimentos armazenam todos os dados históricos ou o histórico de versões. Isso é o que estamos nos referindo como banco de dados de objetos. Bem, atualmente essa pasta não tem muitos dados. Mas assim que fizermos alguns comentários, você verá essa pasta sendo preenchida. Você verá várias pastas sendo criadas. Dentro da pasta de objetos. Temos a pasta ribs, mas isso não fala sobre isso porque para entender isso, você precisa saber o que é um objeto commit, hashing, etc. Então, vamos pular isso por enquanto. Arquivo de conflito é algo que exploraremos na próxima palestra. O arquivo de descrição tem algo a ver com o Git web. E como você não sabe obter web, não faz sentido para mim falar sobre isso. Agora mesmo. A cabeça tem algo a ver com ramificação. Então, falaremos sobre isso. Quando falamos sobre filiais. Vamos seguir em frente. Uma coisa que também devo mencionar é que entrar nele é uma operação segura. Significa que vamos supor que eu trabalhei no meu projeto por um tempo e fiz alguns comentários e, acidentalmente, presumo que executo o comando mais uma vez, dentro do nosso projeto. Isso não causará nenhum dano. Tudo permaneceria como está, como se não tivéssemos executado esse comando. No entanto, se você excluir essa pasta, isso causará problemas. Você perderá todos os dados históricos, todo o histórico de versões, etc. E então você precisaria reinicializar o projeto, mas executar o comando git init e começar do zero. Ou você precisa conferir o projeto no repositório centralizado, que exploraremos nos próximos capítulos. Mas, como regra geral, você deve sempre se lembrar de não mexer nessa pasta, a menos que saiba o que está fazendo. O fato de estar oculto por padrão deve dizer que não se destina a ser usado por desenvolvedores como você e eu, mas para ser usado por si só. No entanto, pode haver casos em que você precise trazer algumas edições ou fazer algo dentro dessa pasta. Por exemplo, já falamos sobre o arquivo de exclusão de informações, onde você pode querer adicionar algumas exclusões. Mas, caso contrário, na maioria dos casos, você não quer mexer com essa pasta. Apenas deixe para pegar. 11. 0110 Configurando credenciais de Git e explorando configurações de sistema global local: Ok, vamos ver como podemos configurar as credenciais do Git e tentar entender seu propósito real. Agora temos um projeto inicializado pelo get com vários arquivos. Vamos agora tentar executar o comando git commit e ver o que acontece. Você ganha 12. Por favor, pergunte a você, por favor me diga quem você é. Agora. A água está pedindo mudanças no commit local para você, mas quem é você? E também forneceu instruções sobre como podemos nos apresentar para obter é executando este comando. Mas não se trata apenas de você se apresentar para obter esse propósito real de configurar essas credenciais. Por exemplo, digamos que um dos membros da sua equipe recebeu um defeito ou um bug atribuído ao nome dele, dizendo que não estamos, o recurso não está funcionando conforme o esperado. No processo de análise do problema, eles querem dar uma olhada em todas as mudanças históricas nesse arquivo. E então eles se deparam com uma mudança introduzida anteriormente, que parece ter causado o problema ou parece ter quebrado um recurso. Adivinha? Eles vão conhecer o nome da pessoa e o endereço de e-mail da pessoa que fez essas alterações. Eles vão entrar em contato com eles e pedir que consertem o bug. Mas como conseguir não. Tudo isso é quando você configura essas credenciais dentro, você obtém, quando você faz um commit e faz push todas essas alterações para o repositório centralizado, que será o GitHub. Ele também armazenará essas informações sobre quem fez as alterações e inclui seu nome e endereço de e-mail. Então, se você introduzir um bom código, alguém voltará e o elogiará. Estão. Se você introduzir código incorreto, alguém voltará e culpará você. Na maioria dos casos, é sempre a culpa, mas não há comentários sobre isso. Então, vamos ver como podemos configurar as credenciais e o get já nos forneceu como fazer isso. Então, vamos usar esse comando, git, config hyphen, hyphen global. Quando definimos essa opção global, isso significa que essas credenciais estão disponíveis em todos os projetos, todos os bons projetos que você cria dentro do seu sistema pertencentes a esse usuário específico. Se você dissesse esses dois sistemas, por exemplo, essas credenciais seriam valiosas em todo o sistema. significa que cada usuário no sistema terá todas essas credenciais aplicáveis. Também temos mais uma opção que diz local. Isso significa que esses condenados só estão disponíveis para o repositório atual em que você está trabalhando. Então, primeiro vamos tentar com o local. Talvez eu vá primeiro definir o nome. Você pode definir qualquer nome de sua escolha, mas tem que ser seu nome. E eu vou apertar Enter. E eu vou definir o e-mail também. Ok, agora vamos dar uma olhada em onde eles estão realmente povoados. Então isso está dentro da pasta. Lembre-se da palestra anterior, mencionei que falaremos sobre esse arquivo de configuração. Bem, é aqui que todas essas credenciais seriam definidas. Agora vamos tentar definir essas credenciais em nível global. Desta vez, isso não seria preenchido no diretório Users dentro da sua unidade C. Deixe-me puxar isso para cima. Então, dentro do diretório do usuário, você deve conseguir localizar a configuração do Git. E isso se refletiria ali. E da mesma forma, se você definir as credenciais de todo o sistema, você pode fazer isso. Não espero que seu computador seja usado por várias pessoas e todas elas estão contribuindo para o seu trabalho. Mas de qualquer forma, vamos configurar isso para o sistema, embora você precise ter permissão. Portanto, isso não inicia o get do menu Iniciar como administrador. E então poderemos definir as credenciais, obter a configuração. Sinto muito, o suposto ser todo o sistema muda o nome do usuário. Eu vou dizer que isso andou e isso seria refletido dentro dos arquivos do programa. Deixe-me levá-la até lá. Dentro dos Arquivos de Programas, obtenha o diretório ETC. Você verá o arquivo de configuração do Git. E é aqui que as credenciais seriam preenchidas. A propósito, também devo mencionar que as credenciais locais substituirão as credenciais globais. E as credenciais globais substituirão as credenciais no nível do sistema. Então, vamos tentar obter as credenciais locais rapidamente. Se eles não estiverem disponíveis. Ele tentará pesquisar as credenciais globais. Caso contrário, a última opção seria essas credenciais do sistema. Se nenhum deles estiver definido, obviamente veremos um erro. Você também pode dar uma olhada nas credenciais executando um comando git config list. Em algum lugar aqui, você verá o nome e o e-mail como celular. Você também pode dar a opção ver um determinado nível de credenciais, digamos local, por exemplo. E você também pode ser mais específico sobre quais informações dentro do Config. Você quer dar uma olhada, vou dar uma olhada no nome de usuário, por exemplo. E isso vai imprimir o valor disso. 12. 0111 Estágio e estado de teste e teste: Vamos ver como podemos preparar arquivos instáveis dentro do repositório Git. E, como mencionei antes, precisamos preparar os arquivos antes de planejarmos enviá-los. Atualmente, temos três arquivos dentro do nosso diretório de trabalho. Vamos planejar comprometê-los. Deixe-me expandir a janela para que você tenha uma visão melhor. Além disso, deixe-me digitar o comando clear para limpar a tela e obter uma nova visualização. Vou fazer um ls para listar todos os arquivos. E atualmente temos três arquivos. Se eu tentei fazer git commit, agora, ele vai reclamar dizendo que não rastreamos arquivos dentro do nosso projeto. Precisamos ter pelo menos um arquivo. Tract terá pelo menos um arquivo na área de preparação para poder confirmar. E é isso que está reclamando. Agora, como salvamos esses arquivos? Recebe o comando, Bem, o bem já nos deu uma pista. É bom em. Então, vamos fazer git add. E eu poderia simplesmente listar todos os arquivos que eu queria confirmar. Por exemplo, um ponto TXT espaço para ponto TXT, e assim por diante. Isso seria útil se você quiser selecionar dois para saber quais arquivos você deseja que ele entre como parte de um recurso específico. No entanto, neste caso, eu gostaria de comprometer tudo. Então eu poderia usar um estilo de caractere curinga. Também posso usar um padrão. Por exemplo, posso dizer estrela ponto TXT, e isso colocaria todos os arquivos com qualquer nome que tenha extensão ponto TXT. Então, vamos executar esse comando. É disso que precisamos. Então, isso agora preparou todos os nossos arquivos na área de preparação. Como nos certificamos de que ele preparou todos os nossos arquivos? Bem, há um comando para verificar o status desse git status. O comando Git status nos mostrará uma lista de arquivos não rastreados, lista de arquivos que estão sendo rastreados, arquivos que são modificados, etc. Este comando será útil para verificar o status do nosso projeto à medida que progredimos neste curso, você entenderá mais sobre esse comando. Então, depois de executar esse comando, nossos arquivos são listados em alterações a serem confirmadas. E também transformou a cor desses arquivos em verde, representando que esses arquivos agora estão sendo rastreados ou que esses arquivos estão na área de preparação no momento. O que diz em casos anteriores, em que todos esses arquivos são listados em arquivos não rastreados e marcados em vermelho. Agora, suponha que eu queira remover um desses arquivos da área de teste, talvez porque eu acidentalmente o adicionei aqui. Como fazemos isso? Bem, Deus já nos deu uma pista sobre o comando que precisamos executar para executar no palco um arquivo que é obter RM com hífen, opção de hífen em cache. Sempre que digo que os caches são indexados ou encenados, todos queremos dizer a mesma coisa. Tenha isso em mente. Então, obtenha hífen RM, hífen em cache. E vou listar nos arquivos que eu queria no palco. Se eu quiser no palco todos os arquivos, eu poderia usar um caractere curinga como esse. E isso estaria no palco de todos os arquivos. Deixe-me fazer isso. Portanto, isso não declarou todos os nossos arquivos para garantir que todos os nossos arquivos estejam no palco. Vamos usar o comando git status. E como você pode ver, de volta à seção de arquivos não rastreados e mais uma vez marcado em vermelho. Vamos adicioná-los novamente. Deixe-me criar no palco um único arquivo, talvez dois pontos TXT. Você precisa ter certeza de usar essa opção em cache. Se você não usar essa opção, esse comando terá um significado diferente, sobre o qual falaremos nas próximas palestras. Isso tem um TXT de dois pontos encenado. Informe-nos, verifique o status do nosso projeto. E como você pode ver, TXT de dois pontos agora está listado em arquivos não rastreados. Mas como os outros dois arquivos estão listados sob mudanças para se tornarem isso. Então, reserve um momento e tente experimentar esses comandos para preparar arquivos instáveis e verificar esses dados simultaneamente. Não comprometa as mudanças ainda. Vamos falar sobre isso na próxima palestra. Mas não hesite ou tenha medo de experimentar todos esses comandos, você pode achar esses comentários são bem simples e diretos neste momento. Mas à medida que progredimos neste curso e à medida que eu introduzo mais e mais comandos git, você começará a sentir que eles são muito confusos. Portanto, a única arma que você tem para evitar esse estado mental confuso. Sua prática, não posso enfatizar o quão importante é praticar todos esses comandos, caso contrário, você logo se confundirá. Vejo você na próxima. 13. 0112 Entendendo o commité com múltiplas usecases: Vamos ver como podemos confirmar nossas alterações no repositório Git. A propósito, quando digo repositório Git, posso me referir à nossa pasta do projeto com pasta dot git. Ou também posso me referir ao armazenamento de dados de objetos que falamos anteriormente. Depende do contexto. Para evitar a confusão, vou chamar nosso diretório de trabalho de nossa pasta de projeto como repositório Git. Vou me referir ao banco de dados de objetos como banco de dados de objetos apenas para evitar confusão. Então, atualmente, temos todos esses arquivos no lugar. Vamos garantir que todos esses arquivos sejam preparados. Eu vou fazer git status. Temos um arquivo que não está preparado. Então, vamos fazer git, adicionar dois pontos TXT para prepará-lo. Vamos fazer o git status mais uma vez. E temos todos os nossos arquivos preparados. Eu vou dizer git commit hyphen m. E então vamos fornecer uma mensagem significativa. Por que precisamos fornecer essa mensagem? Bem, basicamente descreve as mudanças que você está comprometendo mais tarde no tempo, se você ou outra pessoa em sua equipe, o que dar uma olhada em todas as mudanças históricas ou comprometimentos históricos. Eles também conhecem qual comitê examinam sua mensagem. Por exemplo, você pode confirmar alterações para corrigir um bug ou adicionar um recurso. Como uma boa prática. Em aplicativos em tempo real, seguimos um formato específico para essa mensagem. O primeiro será a combinação de caracteres alfanuméricos, que é essencialmente um defeito ou um ID de recurso que você escolhe na sua ferramenta de rastreamento de defeitos. Se você estiver trabalhando para uma organização, pode estar tendo uma ferramenta de rastreamento de defeitos ou recursos. Você escolhe esse ID e o insere aqui. Por exemplo, pode ser algo como WI, alguns códigos numéricos. W significa item de trabalho. Pode ser outra coisa para você. E então você vai produzir uma mensagem descritiva. E mesmo essa mensagem, escolheríamos o título do defeito da ferramenta de rastreamento de defeitos? Vou dizer meu aplicativo funcional ou o que quer que seja. Vamos apertar Enter. E todas as mudanças que foram encenadas agora seriam comprometidas. E para garantir que todos os arquivos sejam confirmados, vamos fazer git status. E não mostra nada, o que significa que não temos nenhum arquivo para ficar viciado. Agora vamos em frente e fazer uma modificação em um dos arquivos existentes em nosso diretório de trabalho. Para isso, vou usar o comando echo apenas para preencher um dos arquivos com um texto. Meu texto no arquivo um, por exemplo. E vou despejar essa mensagem dentro de um arquivo txt de ponto. Este comando é equivalente a abrir o arquivo TXT de um ponto e inserir o texto, meu texto no arquivo um. Deixe-me apertar Enter. Agora vou usar o comando cat para ver o que está dentro do gesto TXT de um ponto que mostrei que temos essa mensagem ali e ela imprime o texto dentro do OneNote dxdy. Tudo bem. Agora, essa é uma mudança que introduzimos, o que significa que precisamos preparar isso para comprometer isso. Então, vamos fazer o git status mais uma vez. Desta vez, vamos dizer que temos um arquivo que foi modificado. Então, precisamos fazer git add para adicionar esse arquivo e trazê-lo para a área de preparo. Status do Git. Ele fica verde, o que significa que está pronto para ser comprometido. Vou usar mais uma vez o comando commit. Comprometa-se com as mudanças. Vamos remover a identificação do defeito por enquanto. Deixe-me dar uma mensagem significativa. Arquivo modificado, um, por exemplo, pressione Enter, get status. E com certeza, temos nossas mudanças comprometidas. Agora vamos considerar um caso de exclusão de um arquivo. Então, para isso, vou usar o comando RPM significa remover. E então vou especificar o nome do arquivo. Vamos começar com ponto txt, postura diferente. Agora, esse comando não é específico para get, esse é um comando Unix típico. Pressione Enter. Farei ls para ver se ele foi excluído e, de fato , foi excluído. Agora, esta é uma nova mudança que é introduzida no projeto. Adivinha? Precisamos prepará-lo e, em seguida, informá-los de que excluímos o arquivo. E isso também se reflete no banco de dados de objetos. Portanto, o git status mostrará que o arquivo foi excluído, mas essa alteração não está preparada. Então, adicione ponto dxdy. Bom status. E temos mudanças que estão prontas para serem editadas. Mais uma vez, git commit com uma mensagem significativa. Desta vez, não deixe-me digitar nenhuma mensagem e clicar em Enter para ver o que acontece. Bem, isso abriria o editor de texto que escolhemos ao instalar o Git. No meu caso, ele tem o Notepad Plus Plus para você, pode ser outra coisa. Aqui, precisamos inserir a mensagem que, de outra forma, entraríamos com opção hífen m quando dizer que excluiu o arquivo. Para salvar o arquivo e simplesmente fechá-lo. E isso comprometeu nossas mudanças. Usamos o comando RM com o humor, o arquivo. E então fizemos o comando git add para preparar essas mudanças. No entanto, podemos fazer essas duas etapas em um objetivo é usar o comando get out desta vez em vez de apenas RM, estou dizendo get RM. Isso não apenas removerá o arquivo, mas também prepararemos essas alterações na área de preparação. Vamos excluir três pontos dx, dy, por exemplo. Eu farei ls. E como você pode ver, o arquivo foi excluído. Mas se eu fizer git status, ao contrário do caso do comando RM, desta vez as alterações já estão preparadas e você pode confirmar as alterações diretamente. Git commit, hífen eles. Três arquivos excluídos. Agora vamos dar uma olhada em toda a lista de commits que fizemos executando o comando git log master. Master é o nome da ramificação e também é a ramificação padrão. Falaremos sobre filiais mais tarde. Mas, por enquanto, basta executar esse comando cegamente para ver toda a lista de commits que você fez. O mais recente seria mostrado na parte superior. Como você pode ver. Temos nosso primeiro commit, mas minha mensagem de aplicativo de trabalho. E então modificamos o arquivo um, excluímos os arquivos para serem excluídos. Arquivo três. Também posso ver o autor que fez isso. É maldoso neste caso para você. Seria o que você inseriu ao configurar as credenciais. Quando temos um repositório centralizado e quando temos uma equipe trabalhando em um projeto, você poderá ver toda a lista de confirmações feitas por vários membros da equipe. E se você identificar um commit que está causando problemas ou que pode estar quebrando um recurso. Você pode entrar em contato com o autor escrevendo um e-mail para ele. 14. 0201 Sha1 Hashing Algoritmo: Vamos esquecer isso por um segundo e vamos tentar entender o que é o algoritmo de hash Chavan. O algoritmo de hash siobhan, ou às vezes referido como função hash, levaria qualquer quantidade arbitrária de dados como entrada. E isso nos dará um HashCode de 40 caracteres com uma saída. O tamanho da entrada não importa. Pode ser tão pequeno quanto um byte, ou pode ser tão grande quanto um GB ou até um TB. Mas a saída resultante sempre será um código hash de 40 caracteres. Mesmo que a entrada seja apenas um único alfabeto, você ainda verá um HashCode de 40 caracteres como saída. Aqui estão algumas das características da função hash. mesma entrada resultaria no mesmo HashCode, não importa quantas vezes você execute, ele pode fornecer a mesma entrada que resultará exatamente no mesmo HashCode. Você não pode gerar dados a partir de um determinado código hash. Embora seja possível converter dados em um código hash, isso não é possível de outra forma. Quero dizer, se eu lhe der um HashCode, ele não pode gerar dados a partir dele. É realmente difícil encontrar outra entrada que resulte no mesmo HashCode, mas não é impossível. Você pode ter outra entrada que pode resultar exatamente no mesmo HashCode. Mas a probabilidade de encontrá-lo para que você nem precise se preocupar com isso. Aqui está outro caso de uso em que o HashCode pode ser usado sempre que usarmos os registros do seu site, inserindo o nome de usuário, senha e outros detalhes. Em vez de armazenar a senha e desenhar o formato de texto dentro do banco de dados, vamos armazenar o código hash dessa senha para que o próximo termo usuário tente fazer login. Vamos executar novamente o algoritmo de hash na senha que eles digitam. E então vamos ver se a saída resultante corresponderia com a do banco de dados. Se ambos corresponderem, o usuário será autenticado e terá acesso concedido. O benefício de armazenar código hash em vez de armazenar a senha bruta em formato textual é que, se um hacker invadir seu sistema, ele obtém acesso a códigos hash, mas não às senhas reais. Eles não podem fazer nada usando o HashCode. Por exemplo, eles não podem fazer login usando o HashCode em nome de um usuário. Todo o algoritmo de hash é usado como medida de segurança. Você pode usar um conjunto para um propósito diferente. E é identificar de forma única vários objetos e obter. E vamos falar sobre isso na próxima palestra. Agora vamos tentar gerar código hash partir do Git Bash usando os comandos git. O comando a ser executado é um bom objeto hash, mas antes disso, vamos usar o comando echo com algum texto. Vou usar o caractere pipe e, em seguida, dizer obter entrada padrão do objeto hash. Ao usar o caractere pipe, estamos dizendo que qualquer saída desse comando seria a entrada desse comando. Essencialmente, estamos tentando obter o HashCode desse texto em particular. Vamos apertar Enter. Recebemos um HashCode para esse texto. E não importa quantas vezes eu execute o mesmo comando, vamos ver exatamente o mesmo HashCode. Mas se eu fizer uma pequena alteração, o código hash resultante seria totalmente diferente do que acabamos de ver. Por exemplo, digamos que eu acabei de adicionar um personagem e pressionar Enter. Você verá que esses dois códigos hash diferem significativamente. Você vai entender mais sobre o HashCode, palestras recebidas. 15. 0202 Git Internals (tudo sobre base de dados de objetos) Parte 1: Para explicar melhor como bons gerentes e armazenam os dados dentro do banco de dados de objetos. Eu apaguei tudo dentro do nosso projeto. Então, todo o nosso histórico passado de commits, todas as mudanças que introduzimos agora se foram para sempre. O que temos aqui é essencialmente um novo diretório. E agora vou lançar o Git Bash aqui e criar vários arquivos e diretórios. Quero criar alguns arquivos nessa pasta. Então, vou usar o comando touch one dot dx dy e dx dy. Isso criou alguns arquivos. Além disso, também vou introduzir um subdiretório dentro do nosso projeto. Ele dá o comando para criar um novo diretório. É MKDIR significa make directory. Vou nomeá-lo como ativos. Portanto, temos ativos que são recriados. Vamos entrar nele e criar um monte de arquivos lá também. Eu vou criar, eu quero usar o comando touch one subdata dxdy, substance ou sub directory, apenas para nossa compreensão. E arquivo TXT de dois subpontos. Vamos também colocar algum conteúdo nesse arquivo. Vamos voltar para o diretório pai, que é o diretório raiz do nosso projeto. Vou usar o comando echo. Arquivo um da próxima geração. Vamos preenchê-lo dentro de um arquivo TXT de ponto. E da mesma forma, vamos preencher algum texto dentro do outro arquivo, fezes, dxdy. Um sub, isso vai para dentro de um subponto dx dy, que está dentro do subdiretório assets. Então, aqui está nossa estrutura de diretórios. Temos um diretório de ativos e alguns arquivos dentro do diretório raiz do projeto. E ativos internos que são verdadeiros. Temos esses dois arquivos. Atualmente, essa pasta não foi inicializada. Então, vamos fazer exatamente isso. Entre nele para inicializar este projeto. E git add todos os arquivos. Git status para ver o status. E como você pode ver, tudo está encenado. Agora vamos confirmar as mudanças. Commit Git. Meu primeiro comentário. Isso deve funcionar. Na próxima palestra, vamos entender os diferentes tipos de objetos que temos no Git e como todos esses arquivos são armazenados dentro do banco de dados get object. Vejo você na próxima. 16. 0202 Git Internals (tudo sobre base de dados de objetos) Parte 2: Vamos falar sobre como ele realmente armazena os dados dentro do banco de dados de objetos. Em nossa palestra anterior, criamos um projeto com vários arquivos e comprometemos essas mudanças. E aqui está a estrutura do projeto que tínhamos. Temos a pasta my app, que é o diretório raiz do projeto. Dentro do qual temos um ponto leva você ao ponto TXT e também a um subdiretório chamado assets. Dentro do diretório de ativos, temos um subponto dx dy e dx dy. Agora vamos dar uma olhada em como esses arquivos são realmente armazenados dentro do banco de dados para o qual precisamos entender vários tipos de objetos que o get has. Primeiro, temos o objeto Blob para cada arquivo exclusivo que você acessa. Há um objeto blob criado dentro do banco de dados. Cada objeto blob armazenaria o conteúdo de seu arquivo correspondente. Por exemplo, podemos ter um objeto Blob criado para um ponto dxdy com todo o seu conteúdo. Cada objeto blob também terá um hash exclusivo. E como você deve ter adivinhado, esse hash seria gerado usando o algoritmo de hash Siobhan. E a entrada desse algoritmo seria o conteúdo do arquivo. Na verdade, não está usando o algoritmo Siobhan para proteger o aplicativo ou algo assim. Ele o está usando para criar um identificador exclusivo para seus objetos. E o conteúdo armazenado dentro do blob não estará em um formato legível por humanos. Ele será armazenado em formato compactado. Assim, eu conseguiria armazená-lo, gerenciá-lo e recuperá-lo com eficiência . No entanto, get também oferece certos comandos usando o que seria capaz ler o conteúdo dentro do blob. Vamos explorar isso nas próximas palestras. Agora, como há quatro arquivos que havíamos confirmado anteriormente, haverá blobs criados dentro do banco de dados junto com o conteúdo correspondente desses arquivos. Em seguida, temos três objetos. objeto de árvore corresponderia a cada diretor no projeto, incluindo o diretório raiz do projeto. E assim como com o objeto Blob, objeto de árvore também terá um cache exclusivo para identificar exclusivamente um objeto de árvore específico. Além disso, ele terá referências e, essencialmente, manterá os códigos hash de outros objetos blob ou três objetos ou combinação de ambos. Por exemplo, temos algumas pastas dentro do nosso projeto. E assim, todos eles serão dois de três objetos criados para cada um desses diretórios. Portanto, teremos um objeto de árvore criado para o diretório de ativos. E dentro desse objeto ele conterá as referências são HashCode de seus arquivos. Nesse caso, esse objeto de árvore conteria o HashCode OPT sub um ponto TXT e subjugado ou TXT. Essencialmente, esses são os hashes das bolhas que correspondem a menos um ponto T se estende até o ponto TXT. E então teremos outro objeto de árvore criado para o diretório do projeto pai. E ele terá o HashCode fora de seus próprios arquivos. Além disso, ele também manterá o HashCode da subárvore, que corresponde ao diretório de ativos. E, claro, cada um desses três objetos teria seu código hash exclusivo para identificá-los de forma exclusiva , para que possam ser referenciados a partir de outros objetos. Em seguida, temos o objeto commit. Mais uma vez, isso terá seu próprio hash exclusivo. E esse hash será gerado com base nas informações do commit, como o nome do autor, endereço de e-mail, a mensagem que foi inserida, a hora em que o commit aconteceu, etc. com base nas informações do commit, como o nome do autor, endereço de e-mail, a mensagem que foi inserida, a hora em que o commit aconteceu, etc. object conteria a referência ou HashCode da árvore pai. Além disso, ele também terá informações sobre o nome do autor , endereço de e-mail, a mensagem que foi digitada durante a confirmação, etc. digitada durante a confirmação, etc informações sobre o nome do autor, endereço de e-mail, a mensagem que foi digitada durante a confirmação, etc. O objeto commit também conterá uma referência ou hashCode do comentário anterior. Você saberá o significado disso nas próximas palestras. Pelas mudanças que acabamos de cometer. É assim que ele armazenaria as informações no banco de dados. Portanto, temos três objetos que correspondem a cada diretor do projeto. E também temos objetos Blob que correspondem a cada arquivo dentro do projeto. Agora, não é necessariamente que, se você tiver dez arquivos criados dentro do seu projeto, teríamos dez blobs criados dentro do banco de dados de objetos. Não precisa necessariamente ser assim. Por exemplo, se você tiver dois arquivos com exatamente o mesmo conteúdo, e ambos gerariam exatamente o mesmo HashCode, por exemplo. Então get não criará dois objetos blob diferentes para isso, ele apenas criará um objeto blob e se referirá a ele. De qualquer forma, mais sobre isso nas próximas palestras. 17. 0204 Git internals Visualizando e lendo objetos Git: Teoricamente, entendemos o quão bom ele realmente gerencia e armazena os dados dentro do banco de dados de objetos. Agora vamos dar uma olhada praticamente para explicar melhor as coisas. Também vou mostrar uma representação gráfica do que estamos fazendo agora no lado direito da tela para que você tenha uma imagem melhor do que estamos fazendo. Então, atualmente, temos apenas um commit. Vamos dar uma olhada nisso. Então eu faço git log para dar uma olhada em toda a lista de commits. Atualmente, só temos um. E como você pode ver, temos informações do autor, data e até mesmo a mensagem do commit. Além disso, também temos um código hash de 140 caracteres. Você consegue adivinhar do que se trata esse código hash? Bem, aqui está o HashCode do objeto commit correspondente a esse commit. Agora, como podemos dar uma olhada no conteúdo dentro desse objeto cometa? Bem, esse próprio HashCode dará uma pista de como podemos navegar até esse objeto commit. Deixe-me mostrar o que quero dizer. Estou dentro do diretório do projeto. Deixe-me ampliá-lo para você. Vou entrar na pasta dot git. E adivinhe em qual pasta precisamos entrar. Essa é a pasta de objetos. Agora, aqui temos várias pastas que não existiam antes de confirmarmos as alterações. Agora, se você olhar para o HashCode e retirar os dois primeiros caracteres, ele diz 95. Precisamos entrar nessa pasta. E então você vê um arquivo com o nome, que é essencialmente os caracteres restantes do HashCode. Portanto, temos 95 ECE, assim por diante. 95 é o nome do diretório e o restante dos caracteres é o nome do arquivo. E isso é o que estamos nos referindo como objeto commit. Se você tentar dar uma olhada no conteúdo dentro dele usando um Bloco de Notas Plus, Plus, você não conseguirá lê-lo porque ele o armazenará em um formato diferente que não é legível por nós. A única maneira de ler o conteúdo é executando o comando get kept file. E então você fornecerá a opção hífen P significa impressão bonita. E vai fornecer o HashCode do objeto que você deseja imprimir de forma bonita. Eu poderia copiar todo o código hash, ou eu poderia simplesmente copiar os primeiros caracteres e colar aqui. E isso imprimiria Watson dentro do objeto cometa. Se você quiser dar uma olhada no tipo do objeto, a opção para isso é hífen d para imprimir o tipo. E isso chegou ao objeto. Vamos imprimir esse objeto mais uma vez. Então, aqui, como mencionei anteriormente, você tem informações sobre o computador do autor e até mesmo a mensagem do commit. Além disso, também temos um HashCode, que na verdade é o HashCode do objeto da árvore pai. Então, vamos dar uma olhada no que está dentro do objeto da árvore. E vou usar o mesmo comando para imprimir o que está dentro do objeto da árvore. Eu posso apenas copiar os primeiros caracteres. Cole aqui. E se você apertar Enter, você vai ver o que está dentro dele. Como precisamos voltar ao diretório raiz, temos um subdiretório e alguns arquivos. E se você der uma olhada no que está dentro desse objeto de árvore, você tem algumas bolhas. Cada blob corresponderia a um arquivo individual. Nesse caso, é um ponto dx dy e dx dy. E então também está apontando para outra árvore, ou está tendo o HashCode desligado e outra árvore ou a subárvore. Assim, podemos entrar na subárvore também. Vamos fazer isso. Obtém a saída. Serão os blobs dos dois arquivos dentro da subpasta. Um subponto leva em subponto TXT. E, a propósito, você pode localizar esses objetos dentro da pasta de objetos. Assim como você localizou o objeto commit. Não é diferente. Já que sou a pasta de objetos. Você encontrará uma pasta. Então, esse é o objeto da subárvore de que estávamos falando. E da mesma forma, você também pode encontrar os objetos blob. Por exemplo, vamos falar sobre esse blob. Começa com 99, então vamos entrar nesse diretório. E esse é um objeto Blob. Vamos tentar imprimir bem esse objeto blob e devemos ser capazes de ver o conteúdo dentro dele. E mais uma vez, se você o abrisse com o Notepad Plus, Plus ou algo assim, você não conseguiria ler. E você vê o texto que está dentro desse arquivo. Então é assim que nós basicamente armazenamos os dados dentro do banco de dados de objetos. E entender isso é muito importante para você entender como os tópicos que discutiremos e os próximos capítulos. 18. 0205 Como se comportar objetos: Vamos falar sobre objetos Blob e como eles são gerenciados dentro do repositório Git. Imagine que eu criei um projeto totalmente novo com o seguinte arquivo, um ponto TXT, e ele tem o seguinte texto nele. Olá de conseguir. Agora, no momento em que adiciono esse arquivo a essa área de teste, get realmente tentará gerar um código hash a partir do conteúdo de um arquivo TXT de ponto. E o get verificará se já temos algum objeto no banco de dados de objetos que corresponda a esse código hash. Se não houver nenhum, então ele iria em frente e criaria um objeto Blob com todo o conteúdo de um arquivo txt de ponto, é claro, em formato compactado. Agora, suponha que eu criei mais um arquivo, digamos dois pontos TXT, com exatamente o mesmo texto que para o áspero ponto TXT hello de obter, mais uma vez, suponha que eu adicionei este arquivo ao área de preparação. Obter largura. Mais uma vez, tente gerar HashCode a partir do conteúdo de um arquivo TXT de dois pontos. E desta vez, vamos notar que já temos um objeto que corresponde a esse HashCode. Portanto, get não criará outro objeto blob. A razão para isso é bastante óbvia. Por que queremos criar exatamente o mesmo objeto blob quando já temos um. Por que não usamos apenas o existente? Faz sentido, certo? Agora vamos dar uma olhada em tudo isso na prática. Por causa deste exemplo e evite qualquer tipo de conclusão. Eu criei uma nova pasta com o nome guia Testes. E é aqui que vamos experimentar e ver o que get blobs pode fazer por nós. Então, deixe-me iniciar e ser atacado nesta pasta. Em primeiro lugar, vamos inicializar o projeto. E deixe-me ir em frente e criar um arquivo com algum conteúdo nele. Eu uso o comando echo. Vou despejar essa mensagem dentro de um arquivo txt de ponto. Este comando não apenas criará um módulo de arquivo TXT de ponto, mas também o preencherá com este conteúdo Hello from getting. Agora vamos entrar no diretório de objetos e ver como ele se comporta. Deixe-me indicar este arquivo, um ponto txt, git add one dot dx dy. E no momento em que faço isso, vemos uma nova pasta sendo criada diretamente dentro de objetos. Adivinha o que é esse arquivo? Bem, este é o objeto Blob para um arquivo TXT de ponto que acabamos de criar. Então, sim, blobs são criados quando o novo estágio do arquivo não é necessariamente quando você confirma as alterações. Quando você confirma as alterações, ele cria o objeto cometa bem como os três objetos que correspondem a um monte de bolhas. Na verdade, esse é o propósito da operação de confirmação. É para criar um instantâneo, salvou o projeto naquele momento específico. Vamos falar sobre instantâneo na próxima palestra. Vamos voltar. Agora vamos ver o que aconteceria se eu criasse outro arquivo com exatamente o mesmo conteúdo. Quanto a isso, muitas vezes, ponto TXT, vou usar o mesmo comando. Mas desta vez vou preencher a mesma mensagem no arquivo ponto TXT. Vamos preparar esse arquivo. Eu farei o status git. E nós temos esses dois arquivos encenados. Mas se você notar, não há nenhum novo objeto criado para o TXT de dois pontos. E eu já expliquei o motivo disso. Como já temos um objeto Blob com exatamente o mesmo conteúdo, get não entra em criar outro objeto. Em outras palavras, no momento em que adicionamos o extra na área de preparação, tentamos gerar o HashCode desse conteúdo. E ele tem que verificar se temos algum objeto existente no banco de dados que corresponda a esse HashCode. Para TXT de dois pontos, temos um blob existente e, portanto, ele não criou outro bloco. O mesmo princípio é aplicável mesmo se você modificar um arquivo. Por exemplo, digamos que eu queira modificar o texto interno para rock dxdy de arquivo para, por exemplo, vamos substituir o texto dentro do arquivo TXT de pontos. Vamos preparar esse arquivo. Agora, você pode adivinhar se vamos ver uma nova pasta sendo criada dentro da pasta de objetos, a resposta é sim, claro. Temos um novo objeto blob criado porque esse conteúdo aqui é único e não há nenhum objeto blob existente para isso. Vamos também criar mais um arquivo, arquivo TXT de três pontos com o mesmo conteúdo que o TXT frequentemente pontual. E vamos escalar esse arquivo git status. E temos esses três arquivos a serem confirmados. Um ponto dx dy e dx dy, ou ter exatamente o mesmo conteúdo enquanto do route dxdy está tendo uma textura diferente. Agora, vamos confirmar as mudanças. Bem, isso não são ofertas, mas seja o que for. Vamos apertar Enter. E como você pode ver, nós criamos tanto o commit quanto o objeto tree, logo após entrarmos nas mudanças. Vamos agora dar uma olhada no que está dentro do objeto da árvore. Vou obter log para obter o HashCode do objeto commit. Item B do arquivo Git cat Vamos verificar o que está dentro desse objeto de árvore. Portanto, tanto um ponto dx, dy, quanto três pontos TXT, devem estar apontando para exatamente o mesmo objeto blob. Se você notar que uma entrada TXT de um ponto ou dxdy estão apontando para exatamente o mesmo objeto blob. Enquanto que para dois pontos TXT, é um objeto Blob diferente. 19. 0206 Coleção de lixo e pacotes: Agora você pode estar tendo uma pergunta. Toda vez que adicionamos um arquivo ou modificamos um arquivo e o trazemos para a área de preparação, veremos o objeto blob sendo criado dentro do banco de dados de objetos. E get não vai nem mesmo excluí-los. Mesmo se você instabilizar os arquivos da área de teste. É eficiente fazer isso ou está ocupando muito espaço? A resposta é que não é totalmente eficiente, é claro. Mas bom tem esse conceito de coleta de lixo, que acontece periodicamente ou quando você executa certos comandos, como get pull, por exemplo, vamos falar sobre git pull, git push comandos, capítulos de entrada, com certeza. Mas existem certos comandos que também acionam a coleta de lixo. O conceito de coleta de lixo é um pouco semelhante à coleta de lixo em outras linguagens de programação. Por exemplo, temos uma coleta de lixo na linguagem de programação Java em que todos os objetos não referenciados seriam destruídos. E o mesmo que acontece com o Git. Não é 100% eficiente, com certeza, mas também tem um mecanismo para gerenciar os objetos com eficiência. Na verdade, podemos executar a coleta de lixo manualmente. Vamos pegar GC. E se você perceber como os objetos que existiam antes não existem mais. Agora, isso significa que tudo correu para o bem? A resposta é não. Ainda temos tudo isso. Por exemplo, se você executar esse comando, ainda veremos como essas informações do objeto e você pode até ler o conteúdo dentro desses objetos blob. Agora, como isso é possível? Não temos essas pastas de objetos, mas ainda conseguimos ler esses objetos. Bem, está dentro desse Diretório. Essencialmente, essa operação de coleta de lixo compactou ainda mais todos esses objetos em um único arquivo de pacote. Também temos idx, nosso arquivo de índice. E isso dirá qual objeto está localizado em qual arquivo anterior. Atualmente, como todo o projeto é muito pequeno, temos apenas um único arquivo de pacote. Mas à medida que temos mais e mais arquivos introduzidos em um projeto, você verá novos arquivos de pacote sendo introduzidos. Um índice entraria em cena naquele momento. Mas de qualquer forma, isso não é algo que realmente precisamos nos preocupar. Você também pode verificar o Watson dentro do arquivo PAC. Deixe-me iniciar o Git Bash nesta pasta. E o comando a ser usado é get, verify back, hyphen v. E então eu vou especificar o nome do arquivo compactado, e isso imprimiria todos os objetos nele. Uma coisa que também devo mencionar é que a tecnologia é viciante. Se quisermos aprender tudo. O céu é o limite de quão profundo podemos ir e entender cada conceito. Mas vale a pena? Essa é a questão. Você realmente não quer aprender tudo lá fora. Isso simplesmente não vale a pena. Porque já temos muitas coisas para cobrir e obter é apenas o ponto de partida e sua jornada de DevOps. Para mim, como instrutor, preciso saber e pesquisar sobre tudo. O que de bom tem a oferecer para que eu possa filtrar o que é necessário e o que não é necessário para você. Na verdade, estou hesitante até mesmo em falar sobre esses conceitos, mas senti que entender isso é muito importante para entender todos os conceitos futuros que falaremos sobre os próximos capítulos. Mas por outro lado, estou hesitante em falar sobre todos esses conceitos que não desempenham nenhum papel no seu Gettier. Eu posso fazer isso se eu quiser. Eu posso te ensinar coisas só para provar que tenho conhecimento sobre isso. Mas isso não faz sentido para você ou para mim. Meu trabalho é facilitar seu trabalho, não complicar seu trabalho. E eu preferiria e tentaria o meu melhor para ensinar apenas as coisas que são absolutamente necessárias para o seu trabalho. Você precisa ter isso em mente e não tentar aprender tudo. Esse é um dos maiores aprendizados que tive na minha carreira. Eu só tentei aprender tudo. Na verdade, a tecnologia é muito viciante. Quanto mais você explora, mais você quer saber mais e não vale a pena. É uma espécie de entretenimento em si, uma forma estranha, talvez, mas é para mim. Eu tenho que levar essa dor não para você. 20. 0207 Git Snapshot O que significa tirar um instantâneo: Vamos tentar entender o que é um bom instantâneo. Anteriormente, criamos um projeto em que tínhamos alguns arquivos no diretório raiz do projeto. E também temos um subdiretório dentro do qual temos mais alguns arquivos. Se você pudesse se lembrar de nossas palestras anteriores. Essa era a estrutura de objetos que tínhamos quando fizemos nosso primeiro commit. Deixe-me simplificar esse diagrama para que pareça mais compacto. Agora vamos supor que eu introduzi outro arquivo, c3 dot dxdy com o seguinte texto hello from getting. E eu mantive isso dentro do diretório raiz do projeto, permanece este arquivo. E então eu cometi as mudanças. Agora você pode visualizar como seria a estrutura dos objetos? Para o segundo commit que fazemos? Você imagina algo assim? Portanto, temos um novo blob criado para o arquivo recém-introduzido. Além disso, você espera criar Blobs para cada arquivo no projeto? A resposta é, claro, não. Em vez disso, o git criará um blog para o novo arquivo. E o objeto da árvore raiz do novo commit conterá o hash desse novo blob. E para todos os outros arquivos, já que eles permaneceram como estão e não são modificados, git simplesmente se referirá a seus blobs e três objetos existentes. Em essência, o conteúdo do objeto tree e da segunda coluna, seria exatamente o mesmo que o condensador do objeto tree em nosso primeiro commit, exceto que haverá uma entrada adicional para o arquivo recém-introduzido. Além disso, o objeto commit também manterá a diferença ou o HashCode do commit anterior ou de seu pai. Você saberá o significado disso em capítulos posteriores. Então, o que é esse instantâneo aqui? Bem, essencialmente toda vez que você faz um commit, você está tirando um instantâneo do estado do índice ou da área de preparação no momento em que faz o commit. Basicamente, ele captura aparência de cada arquivo no momento em que você faz o commit. Se você voltar no tempo para um dos commits anteriores, o git terá a capacidade de restaurar todos os arquivos em seu diretório de trabalho para o que eram quando você fez o comentário. Como isso é possível? É por causa do instantâneo. Agora vamos ver tudo isso na prática. Estou dentro da nossa boa e velha pasta do meu aplicativo. Deixe-me ir em frente e criar um novo arquivo. Então temos três pontos dx, dy com algum texto nele. Git adiciona git commit. Segundo commit. Finalmente, estamos fazendo um segundo comentário. Agora vamos em frente e explorar o commit e os três objetos. Vou fazer git log para dar uma olhada em toda a lista de commits. E, a propósito, falando sobre o combate dos pais, quando executamos esse comando git log, ele exibe os detalhes sobre nosso commit recente. E então esse objeto de comentário está tendo os detalhes de seu commit pai, que é isso. E assim o git continuará e exibirá seus detalhes também. No entanto, para esse commit, já que este é o primeiro commit que fizemos, ele não tem nenhum commit pai. E então esse comando deixará de ser executado. De qualquer forma, você entenderá mais sobre os commits dos pais e os próximos capítulos. Então, vamos em frente e explorar o que está de dentro para fora. Compromisso recente. Obter arquivo mantido, hífen P. E como você pode ver, temos o HashCode do objeto da árvore raiz. Além disso, também temos o HashCode do commit pai, que é isso. E então as informações do autor, etc. Vamos ver o que está dentro desse arquivo. Então, aqui está o conteúdo do objeto da árvore. Vamos compará-lo com o objeto de árvore da nossa primeira conexão. Se você notar, o HashCode do objeto da subárvore é exatamente o mesmo. Hashcode de um ponto dx dy e dx dy são exatamente os mesmos, exceto pelo recém-introduzido no arquivo de três pontos dx dy. Então isso explica. 21. 0208 Viagem no tempo com o Git: Vamos ver como podemos chegar a viagem no tempo. Quero dizer, vou provar isso para você daqui a pouco. Digamos que você desça pelo recurso um e comete todas essas alterações como parte do seu primeiro commit. E vamos supor que todas essas mudanças tenham entrado em um ponto TXT. E então seu cliente diz que precisava de outro recurso em seu aplicativo. Então você quer pegar e trabalhar nisso, fazer outro commit e assumir que todas essas alterações foram para o arquivo TXT de pontos. Mais uma vez, seu cliente tem uma ideia criativa. Ele precisava de mais um recurso em seu aplicativo. E mais uma vez, você trabalha nesse recurso, faz outro commit. E então vamos dizer que você introduziu TXT de três pontos onde você tem todas essas três mudanças de recurso. Agora, digamos que, por algum motivo, o cliente tenha decidido não ter o recurso três por qualquer motivo. E que ele queria voltar para a versão anterior deste aplicativo. Então, como você reverte todas as três alterações do recurso? Bem, neste exemplo, é bem fácil. Você acabou de excluir o arquivo TXT de três pontos e depois fazer outro commit. No entanto, como discutimos em um de nossos capítulos anteriores, desviar alterações não é uma tarefa fácil, pois em aplicativos do mundo real, você pode ter alterações espalhadas por vários arquivos. E é muito difícil reverter todas essas mudanças sem bagunçar as coisas. Você pode acabar quebrando recursos que estão funcionando anteriormente. Felizmente com o get seria capaz de voltar à cópia de trabalho anterior do nosso projeto. Agora também devo mencionar que, qualquer que seja a abordagem sobre a qual vou falar para ir para a versão anterior do projeto, não é realmente a abordagem recomendada. A abordagem recomendada é usar ramificações, sobre as quais falaremos no próximo capítulo. E no próximo capítulo, você também entenderá por que essa não é a abordagem recomendada para desviar suas mudanças. Mas, por enquanto, vamos dar uma olhada nisso em ação. 22. 0209 Viagem de tempo na prática: Ok, vamos ver como podemos viajar no tempo e começar com um exemplo rápido. E mais uma vez, para evitar confusão, acabei de limpar tudo dentro da pasta da área de trabalho e vamos fazer tudo do zero. Deixe-me lançar e o Git Bash. Meu plano é fazer três commits. E assumimos que cada comentário corresponderia a características individuais. Inicialize o projeto. Toque em um ponto TXT, git add. Vamos ficar como esse arquivo, git commit. E vamos chamá-lo de qualquer um. Vamos repetir o processo para adicionar o recurso também. Vamos chamá-lo de dois pontos TXT. Git adiciona dois pontos TXT e git commit. Recurso dois. Vamos fazer um último commit representando o recurso três. E o git commit apresentava três. Agora vamos fazer git log para dar uma olhada em toda a lista de objetos. Deixe-me ampliar essa pasta para que possamos simultaneamente dar uma olhada no que está acontecendo aqui enquanto executamos os comandos. Então, atualmente, temos esses três arquivos. Agora, vamos supor que eu queria recompensar e voltar para uma das versões anteriores do projeto. Digamos que eu quisesse voltar à aparência do meu projeto. Eu fiz um recurso para chegar. O comando que eu preciso usar é, na verdade, switch. Agora, observe que esse comando pode não estar funcionando para você se você tiver versões mais antigas do Git instaladas. Portanto, baixe e instale a versão mais recente do Git somente então esse comando será executado. Se você ainda insiste em usar versões anteriores do gaped, então há outro comando chamado git checkout. Você precisa digitar isso. E se você tiver a versão mais recente instalada, como no meu caso, esses dois comandos funcionarão sem nenhum problema. No entanto, eu prefiro usar o switch. E então vamos fornecer o HashCode do combate ao qual queremos nos dedicar. Deixe-me colar o código. Você não precisa colar o código inteiro. Os primeiros personagens seriam suficientes. Agora, se eu apertar Enter, vamos receber uma dica de get's dizendo, se você quiser desanexar, vá para o commit, tente novamente com a opção desanexar. Bem, tudo o que estamos fazendo agora é na verdade chamado de estado principal desapegado. Você vai entender sobre isso no próximo capítulo e entender isso também dizendo que uma ramificação é esperada. Mas foi comprometido. Como eu disse antes, o que quer que estejamos fazendo agora não é realmente a abordagem recomendada. A abordagem recomendada é, na verdade, usar ramificações. Mais uma vez, falaremos sobre isso no próximo capítulo. Isso é o que o Git está até recomendando. Ele espera que usemos um ramo e não um cometa. Vamos continuar incluindo a opção de separação de hífen e hífen. E se você notar no momento em que executamos esse comando, você não vê mais o arquivo TXT de três pontos. E mesmo se você fosse dar uma olhada em toda a lista de commits, fazendo git log. Ele vai imprimir apenas dois commits. Essencialmente. Acabamos de voltar no tempo para trazer de volta ao projeto o que era quando eles criaram um recurso para se comprometer. É equivalente a, eu não fiz nenhuma mudança depois que eu fiz o recurso para chegar. Quão legal é isso? Você também pode ir para o futuro. E eu não estou errado em dizer isso. Deixe-me criar o HashCode do recurso três. Desta vez. Deixe-me executar git checkout e Strauss, que então vou especificar o hash do terceiro commit, nosso commit da árvore de recursos. E dê uma olhada no que aconteceria dentro do nosso diretório de trabalho. Bem, você vê três dx, dy novamente, estamos de volta ao futuro. Quão legal é isso? Eu gostaria que houvesse algo assim em nossas vidas. Quero dizer, eu poderia simplesmente voltar no tempo, consertar as coisas, talvez investir em Bitcoin e voltar para o futuro. Quão legal seria? Só é possível e consegue, no momento. É loucura, mas ao mesmo tempo meio assustador para ser honesto, mas esse é o poder do bem. Mas, de qualquer forma, tente experimentar esse recurso. Apenas brinque com isso. E não se preocupe com terminologias como cabeça, ramo, etc. Vamos falar sobre tudo isso no próximo capítulo. Mais uma coisa que devo mencionar é que sempre que estamos trocando ou verificando outro commit, Get conseguiu trazer de volta o diretório de trabalho de volta ao que era quando fizemos esse comentário. E isso aconteceu muito rapidamente. A razão pela qual isso acontece tão rapidamente é por causa do conceito de instantâneo que discutimos em uma de nossas palestras anteriores. Em outros sistemas de controle de versão. Qual é a história, na verdade, a diferença de arquivos em comparação com seus commits anteriores. E quando adicionamos a ferramenta para trazer de volta o projeto a um determinado estado, na verdade vai resumir todas as diferenças para recriar os arquivos para o que eles eram quando fizemos o commit. No entanto, no caso de get, é tudo sobre Snapshot. Basicamente, todo e qualquer objeto commit aponta para um snapshot ou o objeto da árvore raiz, que tem todas as informações de todos os arquivos que residem em nosso diretório de trabalho e todos os seus objetos blob correspondentes. Portanto, é relativamente mais rápido. Esqueça de recuperar o conteúdo dos objetos Blob e quase instantaneamente ou rapidamente carregar quase instantaneamente ou rapidamente todos os arquivos no diretório de trabalho. Esse é o poder de armazenar um instantâneo em comparação com armazenar as diferenças em conjuntos de almofadas como discutimos em uma de nossas palestras anteriores. É como quando você está jogando um jogo, você vai e volta entre vários pontos de venda. Algo parecido com isso. Espero que faça sentido. 23. 0301 Vida sem ramos: Vamos ver como a vida dele antes do git branches existia. E você pode dizer por essa imagem que deve ser uma experiência muito frustrante. Imagine que temos Bob, que é consultor de investimentos e remetente, que é freelancer. Bob à parte para criar um aplicativo para ele. E o remetente criou um aplicativo e Bob está muito feliz com o funcionamento do aplicativo. E agora Bob decidiu adicionar mais alguns recursos em seu aplicativo. E o remetente aceitou trabalhar nesses recursos. Agora, suponha que o remetente começou a usar o recurso um e confirmou todas essas alterações e o mostrou a Bob. Bob está muito feliz com a forma como o recurso está funcionando. E ele deu sinal verde para continuar trabalhando em outros recursos. Portanto, o remetente continuou trabalhando no recurso também. E enviou um e-mail para Bob pedindo que ele verificasse o recurso. Mas desta vez Bob está bastante ocupado com esses clientes. E então ele não teve tempo para verificar esse recurso. No entanto, alguns decidiram continuar trabalhando em outros recursos porque se ele continuar esperando pela resposta de Bob, ele pode não conseguir cumprir o prazo do projeto. Então, ele entregou o recurso três e o recurso para também, e enviou um e-mail para Bob pedindo que ele verificasse todos esses recursos. Bob verificou todos os recursos. E, por alguma razão, Bob não está satisfeito com o recurso para finalizar que ele decidiu eliminar esse recurso completamente de seu aplicativo. Então Cinder pensou um pouco sobre isso e percebeu que é realmente difícil desfazer todas essas mudanças. Porque se ele tentar desfazer todas essas mudanças, ele pode acabar quebrando algumas das características que estavam andando. Outra coisa que está pensando em fazer é voltar para uma das versões anteriores do projeto executando o comando gets que são git checkout. Mas o problema com isso é que Cinder não só se livrará do recurso das mudanças, mas ele também se livrará do recurso três e recurso para mudanças que estão funcionando bem. E Bob está muito feliz com esses recursos. Esta é apenas a ponta do iceberg quanto ao tipo de problema que podemos enfrentar quando não usamos galhos. Por exemplo, em aplicativos do mundo real, você pode não ser a única pessoa que trabalhará no aplicativo. Você pode ter a base de código e a lista de históricos de confirmação, decidir sobre um repositório centralizado e vários membros da equipe e poderia ser de várias equipes, estaria contribuindo para esse projeto. Todos faziam seus próprios commits, introduzindo seus próprios recursos. Agora não podemos arriscar voltar para uma das versões anteriores e correr o risco de perder todo o esforço da equipe. Outro problema que você pode enfrentar sem ramificações é quando você deseja trabalhar em vários recursos simultaneamente. Deixe-me explicar o que quero dizer. Suponha que você tenha recebido todos esses recursos e precise concluí-los antes de um prazo. Vamos chamá-los de recurso F1, F2, F3 e F4. Embora não seja recomendado que você faça várias tarefas, às vezes a situação de uso pode exigir que você trabalhe em várias coisas simultaneamente. Por exemplo, suponha que você começou a trabalhar no recurso F e fez algumas alterações relacionadas ao F1 dentro do seu diretório de trabalho. E então você tem que escrever um e-mail para alguém. E com base na resposta, você gostaria de continuar com o recurso um. Enquanto você espera pela resposta. Não se espera que você assista ao YouTube ou algo assim. Seu chefe esperaria que você assumisse outra tarefa. Talvez comece a trabalhar no recurso para, por exemplo, você pegar o recurso dois e começar a trabalhar nele. Introduza o código relacionado ao recurso dois. E então vamos dizer que você é dependente de outra pessoa para o recurso também. E você tem que esperar pela resposta. Então você pega o recurso três também. Enquanto você gerencia todos esses recursos, aguarda respostas e atualiza o código de acordo. Seu chefe pediria que você enviasse uma atualização sobre o recurso para você. Falaremos sobre o andamento, mesmo que você não tenha iniciado o recurso apenas para mantê-los felizes, você pode dizer a ele que está em andamento. Então você é meio forçado a começar a trabalhar no recurso por enquanto. E então, de repente, você responde pelo recurso um. Ou alguém da sua equipe pede que você entregue recurso três porque eles dependem deles. Espero que você esteja chegando aonde isso está levando. Quando você tiver todas essas alterações parciais de todos os recursos dentro do seu projeto. Isso levaria a muita bagunça e muita frustração. Vamos falar sobre mais um problema realista que você pode enfrentar se não usar branches. Imagine que você tenha um repositório centralizado onde todos os membros da equipe contribuiriam para a base de código. E aí vem essa nova dama que acabou de se juntar à equipe. Ela não tinha nenhuma experiência em programação. Ela acabou de se formar na faculdade e se juntar à organização. E ela foi designada com um recurso para trabalhar. Enquanto ela está trabalhando no longa, ela sentiu que há muitas mudanças para voltar. Então ela pensou em fazer um commit parcial na base de código. Então ela comete essas mudanças. E, obviamente, como você pode esperar, isso não é a coisa ideal a se fazer. Mas ela é nova na equipe. Ela não sabe muitas coisas. Ela ainda está aprendendo e fez um compromisso parcial. E o restante dos membros da equipe começaria a fazer essas novas alterações porque precisam obter o código mais recente para começar a trabalhar em seus próprios recursos em cima do código existente. E eles contribuem para o projeto, introduzindo seu próprio conjunto de mudanças e introduzindo novos recursos ou correções de bugs. Agora, por causa desse comprometimento parcial feito por essa jovem, todos os compromissos futuros podem realmente quebrar também. Ou ainda pior, pode realmente quebrar as coisas maduras, funcionando bem mais cedo. Agora é compreensível que ela seja nova na equipe e ela é obrigada a cometer erros, mas abrigou todos os membros seniores da equipe que fizeram um trabalho justo. Mas ainda assim eles têm que assumir a culpa porque seu código não está funcionando conforme o esperado devido às mudanças introduzidas por essa jovem. Agora, isso é apenas uma consequência do erro cometido por um membro da equipe. Que tal vários membros da equipe introduzirem todas essas ideias meio cozidas na base de código principal. Logo se tornará um pesadelo. Logo se tornará difícil de gerenciar, não conseguindo cumprir os prazos do projeto, muitos problemas para corrigir, etc. Então, acho que agora preciso aprender sobre git branches. Absolutamente. Então o que você está esperando? Cada um encontra essas coisas danificadas. OK. Cilindro fácil. Esse é o plano. É por isso que estou aqui. Estou aqui para te ensinar. Obrigada. Obrigada. Você é bem-vindo. 24. 0302 O que são ramos de Git: Ok, vamos tentar ter uma ideia do que nosso git ramifica. Agora eu tenho que mencionar que com este vídeo sozinho, você pode não ser capaz de entender ou obter imagem completa sobre o que são os branches git. Você precisa assistir todo o resto das palestras deste capítulo para ter uma visão completa do que nosso git ramifica, qual é o propósito, por que eles existiram e como eles resolvem todos os problemas nós tínhamos conversado mais cedo. Então, vamos seguir em frente e tentar obter como equipe, o que eu vou conseguir filiais. ramificações do Git são um recurso tão importante no git que até mesmo o próprio logotipo tem um símbolo que representa as ramificações get. Assim, você pode entender o significado desse recurso no git. Agora eu quero te fazer uma pergunta. Qual é a primeira coisa que vem à sua mente quando você ouve a palavra ramo? Você imaginaria algo assim? Bem, você não está errado. Aqui. Se você observar que temos um ramo principal e também temos sub-ramos que vêm do ramo principal. E cada um desses galhos tem seu próprio conjunto de folhas. Bem, isso é sinônimo que os ramos também não recebem. Então, você pode ter um branch master criado por get quando você inicializa o projeto e faz seu primeiro commit. Não precisamos criar manualmente esse portão, fez isso por nós. E todos os comentários que fizemos até agora foram dentro desse branch padrão, branch master, mesmo que não estejamos cientes disso. E então também podemos ter ramificações de recursos que vêm do branch master. Assim como temos branch principal e sub-branches em um branch do mundo real, também temos branch master e branches de recursos em boas condições. E assim como cada um dos ramos teria seu próprio conjunto de folhas, mesmo no Git, temos convectos residindo em cada um desses ramos. E todos esses ramos evoluiriam de forma independente. Por exemplo, se você fizer um commit e apresentar uma ramificação, essas alterações não estarão disponíveis em nenhuma das outras ramificações. O mesmo que acontece com outras filiais. Se você fizer um comentário e uma ramificação mestre, essas alterações não estarão disponíveis em outras ramificações. Se você quiser fazer um commit em um determinado branch, você precisa mudar para esse branch e fazer um commit nesse branch. E essas mudanças confirmadas não estarão disponíveis em outras filiais. E quando você muda para um branch, git fará com que o diretório de trabalho se pareça com o que era quando você fez o último commit nesse branch específico. Eventualmente, o objetivo de todas essas ramificações de recursos na maioria dos casos seria mesclar na ramificação principal. O que significa que agora teremos todas as alterações introduzidas nas ramificações desse recurso dentro do branch master. Agora, obviamente, isso pode não estar fazendo todo o sentido para você neste momento. Então, vamos detalhar e ver como esse projeto pode ter evoluído desde o início. Então, quando inicialmente for o projeto e fizer seu primeiro commit, você tem um branch master criado por good. E digamos que você tenha feito alguns comentários. Esses comentários entrariam no branch master. Portanto, temos o primeiro commit que não tem nenhum pai. E então você tem o segundo commit, que tem o primeiro commit como seu commit pai. E agora vamos dizer que você está designado para trabalhar no recurso um. Em vez de comprometer todos esses recursos um muda dentro do branch master. O que você vai fazer é executar um comando para criar uma ramificação de recurso. E isso apenas criaria a ramificação do recurso. E depois de fazer isso, você precisa mudar para esse branch para poder fazer commits nesse branch de recurso. Então, você executaria um comando para alternar para esse branch. E depois de fazer isso, você vai começar a introduzir todas as mudanças no recurso. Quando você faz o primeiro comentário. Temos um objeto de comentário cujos pais seriam o último commit do branch de onde você criou esse branch. Nesse caso, é o branch master. Portanto, o primeiro comentário que você fez dentro do recurso um branch agora apontaria para o último commit do branch master. E então, digamos que você tenha feito alguns comentários dentro do branch do recurso. Nenhuma das alterações que introduzimos no branch do recurso um estaria disponível no branch master. Porque, como mencionei antes, todos esses ramos evoluiriam independentemente uns dos outros. Agora, digamos que você tenha decidido trabalhar em outra coisa e queira contribuir com todas essas mudanças dentro do branch master. Então, você mudaria novamente para o branch master e faria um comentário. Observe que esses dois commits ou tendo exatamente o mesmo pai e quaisquer que sejam as alterações que você introduziu com esse novo commit dentro do branch master não serão disponível dentro da ramificação do recurso. branch do recurso um só teria todas as alterações introduzidas no branch master até o momento em que você criou o recurso no branch e fez o primeiro commit. Além de todas as mudanças que você introduziu no recurso um. Ok, digamos que você tenha feito mais um comentário dentro do branch master. E é neste momento, digamos que você seja solicitado a trabalhar no recurso para adivinhar o que você vai criar mais um branch, vamos chamá-lo de recurso para branch. E então você tem que mudar para esse branch para poder fazer commits dentro do recurso para branch, você vai fazer um commit. E desta vez ele ficaria preso dentro de um recurso para ramificar. E esse objeto commit estaria apontando para o último commit até o branch master, porque é o branch master de onde criamos esse recurso para ramificar. E todos os commits subsequentes que você fará serão rastreados dentro do recurso para o branch. Agora, mais uma vez, você pode querer voltar para o branch master e fazer um monte de comentários e não o recurso de dimensão para o branch terá alterações que você introduziu no branch master até a hora em que você criou o recurso para ramificar e fez o primeiro commit. E todos os comentários que você introduziu em feature to branch, mas não tem nenhuma das alterações que você introduziu em nenhum dos outros branches. Como, por exemplo, apresentar um ramo. Eventualmente, você deseja mesclar todas as alterações introduzidas nesta ramificação de recurso na ramificação mestre para que você tenha todas as alterações dentro da ramificação mestre. Agora, obviamente, você pode estar tendo muitas perguntas sobre como isso resolveria todos os problemas que conversamos anteriormente. E o que exatamente é branch? Como isso funciona internamente? E como isso é gerenciado para o que significa quando você muda para um ramo diferente, você, e encontrar respostas para todas essas perguntas nas próximas palestras. E, a propósito, mencionei que fazemos commits dentro do branch master. Normalmente, não tendemos a fazer commits diretamente dentro do branch master. Sempre criamos um novo branch, recurso beta ou uma correção de bug. E quando tivermos certeza de todas as alterações, depois de testá-las, revisá-las, só então mesclaremos todas essas alterações dentro do branch master. Então, essencialmente, o que o branch master teria é o chamado commit de mesclagem. Falará sobre mesclagem de commits nas próximas palestras. Eu não quero falar sobre isso agora e confundir você ainda mais. Vejo você na próxima. 25. 0303 Como os ramos resolveram nossos problemas: Ok, até agora temos uma ideia sobre filiais. Agora vamos dar uma olhada em como as filiais resolvem os problemas que falamos anteriormente. Vamos falar sobre eles um por um. Imagine que você seja solicitado a trabalhar em vários recursos simultaneamente. Desta vez, você terá várias ramificações, cada uma correspondendo a um recurso individual. É muito fácil para você realizar várias tarefas ao mesmo tempo porque digamos que você queira trabalhar no recurso um. Você simplesmente vai mudar para esse branch e continuar trabalhando no recurso um. Em algum lugar no meio do seu trabalho, você pode ter decidido trabalhar em outro recurso, digamos, recurso para talvez porque você está esperando por uma resposta por e-mail ou qualquer outra coisa. Então adivinha? Ele foi mudar para um recurso para ramificar e continuar trabalhando no recurso dois. E como as mudanças de pelagem introduzidas em um galho não terão nenhum impacto nos outros galhos. Não há chance de você se confundir com as alterações de código introduzidas para vários recursos. Temos contextos separados para cada recurso. E eles evoluem independentemente um do outro. Portanto, as ramificações meio que resolvem o problema de não serem capazes de realizar várias tarefas entre vários recursos. Agora suponha que algum programador inexperiente se juntou à equipe. Adivinha? Eles podem simplesmente criar um ramo, experimentar. Tudo o que eles queriam experimentar, cometer erros, aprender esses erros e trazer atualizações. Finalmente, quando estiverem prontos com as mudanças. E uma vez após o teste, todas essas mudanças, os membros seniores da equipe podem realmente revisar todas as alterações de código. E só então eles aceitarão que todas essas mudanças sejam mescladas com a corrente principal do desenvolvimento. Portanto, não há escopo de um membro da equipe mexer no código e custar o trabalho de outro também. Agora, digamos que você queira se livrar de um dos recursos, então você não precisa tomar o forte deles de desfazer todas as mudanças e arriscar criar problemas. Ou você não precisa voltar a um dos commits anteriores e correr o risco de perder todo o esforço da equipe que veio depois dele. Em vez disso, você pode simplesmente excluir o branch e obtê-lo. O recurso que você não quer. Não terá nenhum tipo de impacto ou influência no trabalho dos outros. Outra vantagem com branches é que você pode fazer commits parciais. Sem as ramificações que fizemos confirmações parciais, você pode correr o risco de introduzir novos bugs em seu aplicativo quebrando alguns dos recursos de trabalho. No entanto, com branches, você pode fazer vários commits parciais, especialmente se seu recurso for muito grande. E quando terminar, você simplesmente irá mesclar todas essas alterações no branch master. Espero que faça sentido. 26. 0304 Como funcionam os ramos de Git e o que é exatamente um ramo: Ok, vamos tentar entender como as filiais funcionariam. Mas antes disso, vamos entender o que exatamente é um ramo. Se eu fosse definir uma ramificação, uma ramificação seria simplesmente uma referência a um commit, ou em outras palavras, é apenas um ponteiro para um commit específico. Agora você deve estar se perguntando por que algo tão simples como isso pode fazer tanto por nós? Isso faz. Deixe-me explicar o que quero dizer. Vamos configurar isso. Basta inicializar o projeto usando o comando git init. E como branch é uma referência a um commit específico, precisamos de pelo menos um commit para ter um branch. E é por isso que você não está vendo nada agora. Uma ramificação seria criada na primeira vez que fizéssemos um commit. E esse branch é o branch master, que seria criado pelo próprio Git. Não precisamos fazer isso manualmente. Você pode pensar nisso como simplesmente um arquivo com o nome Master, cujo conteúdo será o HashCode de um commit específico. E um branch sempre aponta para o último commit nesse branch. Atualmente, temos apenas um único commit. Esse branch master apontaria para esse commit. Agora, digamos que eu fiz um novo commit, então o branch agora apontaria para esse novo commit, e assim por diante. E fazer um novo commit e branch apontaria para esse novo commit. Agora, digamos que eu tenha que andar no primeiro recurso. Vamos executar um comando para criar outro branch. Vamos chamá-lo de feature one branch. No momento em que você executar esse comando, o git criará um novo branch, essencialmente um novo arquivo com o nome feature one, cujo conteúdo seria o HashCode de um commit específico. O que seria? Você pode fazer um palpite? Bem, seria o último commit fora do branch de onde criamos o recurso um branch. Então, isso apontaria para esse commit. Agora vamos dizer que eu fiz mais alguns commits. Onde você acha que esses comentários iriam para Mel? Ele entraria em master porque esta é a ramificação ativa atual. Então, esses dois comentários entrariam no branch master. E como você pode imaginar, master agora apontaria para esse commit muito recente nesse branch específico. Agora, digamos que você queira fazer alguns comentários dentro do branch feature. Bem, você tem que executar um comando para mudar para esse branch. E depois de fazer isso, todos os commits que você vai fazer serão rastreados dentro do branch feature one. Se eu fizer um commit agora, como você acha que seria o diagrama? Bem, um ramo sempre apontaria para o último comentário sobre esse ramo. Recurso. Uma ramificação agora apontaria para esse novo commit. E esse novo commit terá o commit do branch master como seu pai. Portanto, é neste momento que teremos dois commits com exatamente o mesmo pai. Agora vamos dizer que eu fiz mais alguns comentários. Onde você acha que esses comentários seriam rastreados? Bem, já que o ramo do recurso um é o atual ramo do ator, esses comentários entrariam no ramo do recurso um. E, claro, o branch feature one agora apontaria para o último commit nesse branch. Agora, minha pergunta para você, imagine que eu adicionei um arquivo em cada um desses comentários. Agora, se eu fosse olhar para o diretório de trabalho, quais são todos os arquivos que você verá? Você consegue adivinhar? Bem, toda vez que você mudar para um branch, git irá reescrever o diretório de trabalho para se parecer com o que parecia quando você fez o commit mais recente naquele branch para o qual você acabou de mudar. Portanto, nesse caso, as ramificações atuais do ator apresentam um lote. Então você vai ver todos esses arquivos a, B, C e F, G, H. Você não vai ver os arquivos D e E. E agora, se você mudar para a ramificação master, você verá os arquivos A, B, C, D, E , mas não Arquivos F, G, H. Espero que faça sentido. Vejo você na próxima. 27. 0305 ramos em ação (criando ramos e explorando o repositório de git): Ok, vamos ver as ramificações em ação com um exemplo rápido. Mais uma vez, criarei uma nova pasta, meu aplicativo, e é aqui que vamos experimentar tudo sobre branches. Vou lançar o Git Bash aqui. Deixe-me criar um arquivo confirmado na ramificação principal. E vamos começar a partir daí. Vou inicializar o projeto. Em seguida, toque em um ponto TXT para criar esse arquivo. Git adiciona um ponto TXT para permanecer como esse arquivo. E antes que eu confirme as alterações, deixe-me levá-lo para obter o diretório refs, heads. É aqui que ele criaria listas, muitas vezes ramificações. Deixe-me voltar ao Git Bash e comentar essa mudança. Git commit hyphen m. Primeiro commit no branch master. No momento em que eu confirmar essas alterações, você verá um novo arquivo sendo criado pelo gaped. Vamos dar uma olhada no que está dentro desse arquivo. Tomar nota do nome do arquivo é o nome da ramificação, a ramificação padrão que Deus criou para nós. É mestre. E o HashCode é o HashCode do commit que acabamos de fazer. Se eu voltar ao Git Bash e fizer git log, o HashCode que você vê aqui é exatamente o HashCode que você vê dentro do arquivo mestre. Então, essencialmente, o mestre do ramo está apontando para esse cometa em particular no momento. Vamos fazer mais um comentário e ver o que vai acontecer. Toque no arquivo TXT de dois pontos, git, adicione dois pontos TXT. E então, mais uma vez, vamos comprometer a mudança. Vamos chamá-lo de segundo commit e branch master. E vamos dar uma olhada no conteúdo dentro do arquivo mestre. Então cat dot get refs heads e depois o arquivo master. E como você pode ver, Master agora está apontando para o último commit nesta ramificação atual. Então, se eu fizer git log, você verá que o branch master está realmente apontando para o commit muito recente que fizemos. Agora vamos tentar criar uma nova ramificação. E o comando para isso é git branch. E então você especificará o nome da ramificação que deseja criar. Vamos chamá-lo de recurso um. Então, isso criou o recurso um branch, mas ainda estamos no branch master. E você pode dizer isso olhando aqui, diz Master, então estamos atualmente no branch master. Se eu fizer um commit agora, ele não estará disponível. Destaque um ramo. Mas se você notar, ele também criou outro arquivo dentro do diretório heads com o nome feature one e obtém o conteúdo dentro dele. Bem, será o HashCode do último branch commit off de onde criamos o recurso um branch. Então, essencialmente, se você der uma olhada no conteúdo do arquivo de recurso um, ele apontará para o último commit do branch master. Como esperado. Agora, se eu fizer um novo commit onde você acha que as mudanças entrariam, ele estaria dentro do branch master porque esse é o ato atual de ramificar. Então, deixe-me fazer um compromisso. Holandês três pontos dxdy, git add three dot dxdy. E vamos fazer um terceiro commit dentro do branch master. Se eu fizer ls, você verá todos esses três arquivos. Mas se eu mudar para o recurso um branch, então eu recebo switch e o nome do branch para o qual eu quero mudar. Recurso um. Você também pode usar o comando git checkout e o nome do branch head away. Como você pode ver, mudamos para o recurso de um ramo. Você também pode dizer isso olhando aqui. Agora, você consegue adivinhar o que todos os arquivos verão se eu fizer ls? Bem, só devemos ser capazes de ver um ponto dx dy e dx dy. E não liberou dxdy porque o texto de três pontos é criado e o branch master, depois de criarmos esse branch de recurso. Como você pode ver, estamos vendo apenas um ponto d x em arquivos rho TXT, o que é esperado. Agora, já que estamos dentro do branch do recurso um, todos os comentários que vou fazer agora ficariam presos dentro do branch do recurso um. Vamos fazer um comentário. Quero criar um arquivo, toque em. Vamos chamá-lo, que são nomes de arquivos TXT de 13 pontos como este, só para que saibamos que isso pertence ao recurso um ramo. Por enquanto. Adicionar git. Vamos ficar como esse arquivo, git commit m, adicionando o arquivo feature 13 no qual um branch, qualquer que seja. Então fizemos o comentário se eu fizer ls agora, você quer ver todos esses arquivos. Deixe-me voltar. O diretório de trabalho. Você vai ver todos esses arquivos. Bem, vamos dar uma olhada no que aconteceria se eu mudasse para o branch master. Então eu uso gets which command. Ou eu também poderia usar git checkout e depois o nome do branch. No momento em que faço isso, você pode ver que ele atualizou o diretório de trabalho adequado ao branch master. Portanto, fique ciente do instantâneo do último branch master de diamante de commit. E isso fará com que o diretório de trabalho tenha a aparência de quando fizemos o último commit no branch master. E se eu voltar para o branch de recurso, mais uma vez, você verá o diretório de trabalho sendo atualizado de acordo. Não vemos três pontos, docinho. E o branch feature agora apontaria para o último commit feito nesse branch. Portanto, se você der uma olhada no conteúdo da ramificação do recurso um, o HashCode agora é atualizado, apontando para o commit mais recente no futuro um branch. Se você fizer git log, verá que esse é o último commit feito nesse branch. Agora é realmente crucial para você entender exatamente como isso está funcionando. Eu quero que você experimente com isso. Crie arquivos em várias ramificações, alterne entre várias ramificações e tente entender como se comporta bem com as ramificações. Se você não pratica, é quase certo que você vai se confundir logo. Portanto, não hesite em praticar. Você sente que está sabendo de tudo, mas quando você realmente pratica, você pode ter surpresas. Portanto, não hesite em experimentar isso. Reserve um tempo e pratique o que acabei ensinar e certifique-se que você se sinta confortável com os ramos. 28. 0306 Entendendo 'CABEÇA' Chefe de Estado destacado em ação: Vamos entender o que está por vir e obter. Meu branch é uma referência a um commit, relacionado ao ponto a um branch ou a um commit específico. Quando o head aponta para um commit específico, ele é chamado de estado principal desanexado. Deixe-me explicar o que quero dizer. Quando você tem um projeto sem outras ramificações, exceto a ramificação mestre, por padrão, head apontaria para a ramificação mestre. Agora, suponha que você tenha duas ramificações, master e feature one branch. Digamos que você tenha mudado para o recurso um ramo. A cabeça agora apontaria para apresentar um ramo. E com base na cabeça, get saberá em qual ramo ele precisa confirmar as alterações. Se o head estiver apontando para o branch master, git fará os comentários dentro do branch master, ou o head está apontando para algum outro branch como feature one branch. O Git fará commits dentro do recurso em um branch. Você também pode fazer com que a cabeça aponte para um commit específico. E já tínhamos dado uma olhada em um exemplo do mesmo em uma de nossas palestras anteriores. Por exemplo, você poderia dizer git checkout ou good switch. E então você especificará o HashCode de um commit específico para objetos. O head então apontaria para esse commit específico e get atualizará o diretório de trabalho do projeto para se parecer aparência de quando você fez aquele commit específico. E quais são os comentários que você faz durante o estado principal desvinculado? Todos esses comentários serão perdidos quando você voltar para uma das ramificações. Então você deve estar se perguntando por que está nos permitindo fazer checkout ou mudar para um commit específico. Bem, pode haver casos de uso em que você pode querer voltar ao estado anterior do projeto. Por exemplo, digamos que você gostaria de dar uma olhada em como nosso projeto se parece quando você fez um commit específico, Digamos que você gostaria de recuperar algumas das mudanças que foram excluídos anteriormente em um dos comentários anteriores. Bem, você pode verificar o commit específico. Você dá uma olhada em todas as alterações, talvez copie o código que foi excluído e use esse código em seu projeto atual. Uma vez depois de voltar para a ramificação ou outro caso de uso de estado principal desanexado seria, digamos que você queira voltar no tempo e fazer alguns commits experimentais. Mas você não quer que todos esses commits estejam disponíveis em sua base de código. E depois de terminar, você simplesmente voltaria para uma das ramificações e todas as confirmações experimentais seriam perdidas. Agora vamos dar uma olhada em tudo isso em ação. Ok, estamos atualmente dentro da ramificação do recurso um. Em primeiro lugar, vamos tentar localizar onde a cabeça está realmente residindo. Dentro da pasta git. Você vai encontrar esse arquivo com o nome head. Como agora estamos no recurso um ramo, head está apontando para um ramo. Vamos ver o que vai acontecer. Se mudarmos para o branch master. Vamos dar uma olhada no conteúdo do arquivo head dot get. E como você pode ver, head agora está apontando para o branch master. Agora vamos dar uma olhada na lista de commits neste branch master, git log. E como você pode ver, atualmente temos três commits. E você também pode ver aqui que a cabeça está apontando para o ramo principal. Se você fosse mudar para o recurso um ramo, digamos. E faça git log, por exemplo. Você vai ver que a cabeça está apontando para apresentar um galho. Se você quiser dar uma olhada em toda a lista de branches disponíveis, ele dirá git branch. E então você verá toda a lista de filiais. E como o ramo atual ou o ACT para ramificar ou o chamado ramo principal é um recurso de um ramo, ele é destacado em verde. Também vemos uma marca de estrela nos dando uma pista de que esse é o ramo real ou o ramo atual. Então, se eu fizer git log, você pode ver que atualmente temos três commits. Já demos uma olhada em como podemos conferir ou mudar para um dos comentários anteriores em uma de nossas palestras anteriores. Então, eu não vou fazer isso. Em vez disso, eu usaria um comando diferente chamado Git checkout. Ou você também pode usar um bom interruptor. Vamos usar isso porque é o mais recente. E então você vai dizer cabeça em maiúsculas. E então você vai usar esse símbolo, seja lá o que for. E então você vai especificar o número de commits para os quais você gostaria de voltar. Digamos que se eu disser um aqui, então podemos ver o depositário ou o diretório de trabalho, como parecia um commit atrás. Deixe-me executar esse comando. E desta vez, se eu fizer git log, ok, esse comando basicamente não funcionou. Ele está nos pedindo para adicionar essa opção desanexar. Então, vamos fazer isso rapidamente. Agora vamos fazer o git log. E você só verá alguns comentários. Agora, atualmente, estamos no estado principal independente. Então, deixe-me tentar fazer um comentário aqui. Toque talvez no ponto Apple dx, dy. E então git, adicione apple dot TXT. Chegue, venha, hífen eles. Alguma mensagem. Isso não importa. Se eu fizer git log. Você certamente veria esse compromisso. Mas quando eu voltar para uma das ramificações, você não verá mais esse commit. Esse commit seria perdido. Então, vou fazer o git checkout. Ou você também pode dizer, Good Switch feature one, git log. E você não veria mais o comentário que acabamos de fazer. 29. 0307 Desfaça as mudanças com o Git Reset HEAD: Ok, vamos ver como podemos desfazer nossas alterações e reverter os comentários que fizemos. Para economizar seu tempo. Na verdade, criei uma nova pasta ou um projeto totalmente novo. E basicamente temos esses três arquivos. Cada um desses arquivos foi confirmado em seus próprios comentários. Por exemplo, se eu fizer git log, você verá que temos três commits. No primeiro comentário, eu cometi um arquivo TXT de ponto. No segundo comentário, eu me comprometi com o arquivo TXT de pontos e inseri commit. Nós comprometemos o arquivo TXT de três pontos. Isso é só para economizar seu tempo. Estamos criando projetos e criando arquivos e adicionando-os à área de preparação e comprometendo essas alterações há algum tempo. Espero não ter que te guiar por isso de novo e de novo. Não temos nenhuma outra filial no momento. Temos o branch master padrão. Vamos dar uma olhada em como podemos fazer também mudanças nosso grupo de commits desfazer. E também falaremos sobre mais alguns comentários que considero relevantes para falar agora. Então, digamos que eu tenha cometido essas mudanças acidentalmente e queria desfazer essas alterações. Agora, existem três opções para mim. Eu posso simplesmente desfazer esse commit, mas manter os arquivos no diretório de trabalho. Essa é a opção um. A segunda opção é que eu posso desfazer esse commit, manter as alterações no diretório de trabalho e também ter esses arquivos preparados. E então a terceira opção, eu desfaço esse commit excluo todas as alterações que foram feitas neste comentário. Então, deixe-me demonstrar todos esses cenários. E o comando para isso é git reset. E eu vou dizer cabeça. O que é o símbolo? Não sei qual é o símbolo. Acho que se chama Tilda. Se eu não estiver errado, espero estar certo. E então eu vou dar um número aqui. Se eu especificar dois aqui, gostaria de desfazer os comentários. Vamos tentar com um commit. Eu pressiono Enter. Então, o que isso fez foi desfazer o último commit. Mas ainda temos os arquivos dentro do diretório de trabalho, mas não na área de preparação. Então, se eu fizer git log agora, você só verá o primeiro, o segundo commit. Mas se eu fizer ls, você verá um arquivo TXT de três pontos. Porque, como mencionei antes, ainda temos as alterações no diretório de trabalho. Se eu fizer git status agora, você verá que esse arquivo não está preparado. Assim, podemos apresentar todas as mudanças que queríamos introduzir. Faça todas as atualizações. Assim que fiz algumas alterações no arquivo TXT de três pontos que agora eu queria confirmar. Portanto, posso chamar essas alterações assim que eu tiver feito essas alterações, vou adicionar o arquivo dot txt novamente. E então vou refazer o commit git log. Agora, você vê que temos todos esses três comentários. Agora vamos ver o que aconteceria se eu executasse esse comando com a opção soft, isso para Lambda, esse combate. Mas ainda temos os arquivos dentro do diretório de trabalho , bem como na área de preparação. Eu executo esse comando. Registro do Git. Você vê apenas dois commits. E se você fizer ls, você verá todos os três arquivos. Se você fizer git status, também verá que essas mudanças estão preparadas. Então eu posso simplesmente comprometer essas mudanças. Vou fazer esse comentário. E a vida voltou ao normal. Agora vamos dizer que eu cometi um erro terrível. E eu só gostaria de não apenas desfazer essas mudanças estão sob o commit, mas também gostaria de me livrar de todas as mudanças que fiz nesse comentário. Bem, a opção para isso é que você precisa usar git reset head tilda, número de comentários que você gostaria de voltar. E então você vai usar a opção com força. Agora, se você fizer git log, obviamente verá dois commits. Mas se você fizer isso agora, você só verá dois arquivos. É como se eu nunca tivesse feito o terceiro comentário. 30. 0308 Recuperando o mistério perdido: Agora vamos supor que você mudou de ideia. Você sente que acidentalmente desfez o retorno e gostaria recuperar todas essas mudanças. Bem, há uma maneira de fazer isso. Felizmente, vamos manter esses objetos de commit e seu repositório por um bom período de tempo antes que ele decida excluí-los. Quando faz a coleta de lixo e tudo mais. Então, vamos dar uma olhada se podemos recuperar todas essas mudanças. Em primeiro lugar, precisamos obter o HashCode do commit. Essas mudanças gostariam de recuperar. Então, como sabemos o ID do commit? Agora podemos simplesmente rolar para cima e obter o ID do commit. Mas talvez você não consiga rolar para cima todas as vezes. Por exemplo, se eu fechar esta janela e reabrir, ela sumiu. Então, como podemos ser retirados do ID do commit? Bem, get oferece um comando que nos ajudará, pois apenas esse comando é log, nosso log de referência. Sempre que atualizamos nossos amigos no repositório local. Mas, ao executar um comando, os logs de referência têm um registro disso. E você pode ver todos esses registros executando esse comando. Aqui, você pode se apossar do HashCode desse commit. Bem, agora eu poderia simplesmente adicionar git checkout e ir para esse commit. E isso nos levaria a um estado principal desapegado. No entanto, você pode simplesmente copiar todas essas alterações, trazer todas essas alterações e fazer um novo commit. Mas temos uma maneira melhor de lidar com isso. Então, em vez de fazer git checkout e especificar o HashCode desse commit. O que vamos fazer é especificar a opção hífen b e especificar um nome. E esse nome será essencialmente o nome da ramificação que estamos prestes a criar. Por exemplo, digamos nova ramificação. A propósito, para nomes de filiais, nunca usaríamos espaços em branco. vez disso, gostaríamos de usar hífen. Então, o que esse comando faz é quando temos essa opção hífen b, isso não apenas criará essa ramificação específica, mas também mudaremos para essa ramificação. E isso vai apontar para esse comentário. Vamos executar esse comando. E como você pode ver, mudamos para o novo ramo que acabamos de criar. E se eu fizer git log agora, você pode ver que temos o terceiro e os outros dois comentários são, na verdade, do branch master e escalar o branch de onde criamos esse branch. Mas como obtemos as três alterações de commit em nosso branch master? Bem, podemos fazer isso com o emerge. Não falamos sobre fusões. Falaremos sobre isso nas próximas palestras. Mas talvez eu apenas demonstre rapidamente para você, apenas para lhe dar uma ideia do que é uma fusão. Então, para isso, eu gostaria de voltar para o branch master. Vou usar o comando git, merge out, merge out, especificar o branch que eu gostaria de mesclar no branch master. Nesse caso, é um novo ramo. Agora, se eu fizer git log dentro do branch master, você verá que temos essas novas mudanças. O que acabamos de fazer agora é chamado de fusão rápida. Novamente, vamos falar sobre mais apenas nas próximas palestras. Não pense muito nisso. Uma última coisa que eu gostaria de mencionar é que quando você reverte as alterações ou reverte um commit. Mas se você já enviou essas alterações para o repositório remoto, isso criará um problema. Agora, como não falamos sobre repositório centralizado e colaboração em equipe, não vou falar sobre o Seder, mas como regra geral, lembre-se, se você quiser desfazer o Commit, faça isso antes de realmente enviar todas essas alterações para o repositório remoto. 31. 0401 Fast Forward: O objetivo de ter um recurso ou uma ramificação corrigida de bug é eventualmente mesclar todas essas mudanças dentro do mainstream da evolução, que normalmente seria o branch master. Neste vídeo, vamos falar sobre o que é fusão rápida. Imagine que você tenha um projeto com branch master e com esses três comentários. E é neste momento que decidi trabalhar no primeiro recurso. E então eu criei um branch de recurso e também fiz vários commits nele. Agora, digamos que não temos nenhum outro comentário adicional no branch master. Depois de criar a ramificação do recurso, digamos que terminei todo o trabalho tenho que fazer dentro da ramificação do recurso um. Eu testei todas essas mudanças. E agora eu quero ter todo o recurso um branch muda dentro do branch master. Ou em outras palavras, eu quero mesclar o branch feature one no branch master. Agora, uma pergunta para você, o que posso fazer aqui para que o branch master, teremos todas as mudanças do recurso um branch. Pause o vídeo e tente descobrir. Bem, deixe-me dar uma pista. Vou reescrever esse diagrama disso para isso. Eu não fiz nada. Acabei de levantar o recurso um galho, mas para cima. Mas isso deve lhe dar alguma pista sobre o que podemos fazer para ter todas as mudanças do recurso um dentro do branch master. Experimente. Bem, vou te dar outra pista. Estamos chamando isso de fusão rápida pelo motivo. Qual é a parte do FastForward nisso? Bem, que tal pedirmos ao Master para apontar para o commit mais recente ou apresentar um branch. Isso não resolveria o problema? Essencialmente, o ramo mestre passou encaminhado para um monte de cometas. O branch master agora está apontando para um commit que tem um instantâneo que está apontando para todas as mudanças do branch master mais todas as mudanças no recurso um branch. E já que terminamos com o recurso um branch e eu mesclei todas essas mudanças dentro do branch master. Podemos seguir em frente e excluir esse branch completamente. Agora, a mesclagem de avanço rápido só funcionaria se você não fizesse nenhum comentário dentro da ramificação mestre depois de criar a ramificação de recurso. Agora, outra pergunta para você. Acabamos de ver como podemos mesclar todas as alterações do branch do recurso um no branch master usando a mesclagem de avanço rápido. Agora faria sentido dizer que eu queria mesclar todas as alterações do branch master no branch feature one. Não faz sentido porque o recurso um branch já está tendo todos os commits são todas as mudanças do branch master. No entanto, se você fez comentários no branch master depois de criar o branch de recurso, essa é uma história completamente diferente. E vamos falar sobre isso nas próximas palestras. No próximo vídeo, vamos dar uma olhada em toda essa inação. Vejo você na próxima. 32. 0402 Junta rápida frente em ação: Para explicar o avanço rápido do Merge, eu trouxe o projeto para esse estado. Temos o branch master com esses três arquivos, ABC, e eles são entregues em três commits diferentes. Da mesma forma, temos um branch com os arquivos D, E, F, e todos eles são entregues em três comentários diferentes também. Agora vamos dar uma olhada no avanço rápido de muita inação. À esquerda, temos o Git Bash. À direita, temos o diretório de trabalho. Você pode observar simultaneamente o que está acontecendo no diretório de trabalho enquanto executamos comandos no Git Bash. Atualmente, estou no branch master e você está vendo arquivos ABC. Se eu fosse mudar para o branch de recurso, você verá que o diretório de trabalho seria preenchido com todos os arquivos, o que inclui alterações no branch master, bem como no branch do recurso. Agora vamos dar uma olhada em quem compromete essa marca apenas apontando. Eu vou fazer git refs, chefe mestre. E da mesma forma, vamos dar uma olhada no que as ramificações de recursos querem. E se eu fizer git log, você pode ver que o branch do recurso está apontando para o commit mais recente, mas o branch master está apontando para o commit mais recente no branch master, o que seria isso. Agora não consigo mesclar o branch master no branch de recurso porque os branches de recursos já têm todas as alterações do branch master, isso não faz sentido. Então, precisamos voltar para o branch master. E então eles perceberão que queremos trazer todas as mudanças do branch de recurso para o branch master. E uma vez que eu execute esse comando, devemos ser capazes de ver o branch master apontando para esse commit. Então, ele obtém o comando git merge name do branch que você deseja mesclar. Neste caso, é o recurso de uma ramificação. E como você pode ver, o resumo mostra que esses são todos os arquivos que agora fazem parte da ramificação mestre. E até mesmo o diretório de trabalho é atualizado com todos esses arquivos. Se você der uma olhada em qual branch master está apontando, ele apontará para o commit exato. Essa ramificação de recurso está apontando. Isso é muito rápido para você. Agora podemos seguir em frente e excluir a ramificação do recurso, mas falaremos sobre isso na próxima palestra. Uma coisa que eu gostaria de mencionar é que você pode não querer sempre excluir o branch depois de terminar com ele. Às vezes, você pode querer mantê-lo por um tempo, porque pode haver casos em que você pode precisar fazer essas alterações de última hora. Ou pode haver certas correções que você deseja entregar como parte da mesma ramificação. Então, você vai usar o mesmo branch de recurso novamente para fazer todas essas alterações, testá-las, revisá-las e, eventualmente, mesclar todas essas alterações no branch master. E sim, você pode reutilizar a mesma ramificação e mesclar a mesma ramificação repetidamente. No entanto, na maioria das vezes, criamos outro branch para correções de bugs ou qualquer uma dessas alterações de última hora e, em seguida, mesclamos essas alterações no branch master. Outra coisa que eu gostaria de mencionar é que normalmente acontece no GitHub em um estofamento centralizado. Como não exploramos o GitHub, não faz sentido falar sobre isso agora. Mas, no entanto, a fusão também é o depositário local de Londres em certos casos. Vejo você no próximo. 33. 0403 Apagar o ramo e recuperar: Vamos ver como podemos excluir uma ramificação para explicar isso. Mais uma vez, trouxe o projeto de volta a esse estado. Atualmente, estou dentro da foto um galho. Se eu tentar excluir o branch quando estiver realmente nele, ele lançará um erro dizendo que você não pode excluir um branch jet dot. Deixe-me tentar fazer isso. Então, o comando que eu preciso usar para excluir os branches, git branch. E então vou usar a opção hífen D, ter certeza de que é d minúsculo E depois vou especificar o nome do ramo. Veremos um erro e ele diz que não é possível excluir recurso de ramificação que foi retirado na pasta fulano. Vou voltar para o branch master para poder excluir o branch do recurso um. Se eu tentar excluir agora, get to vai realmente nos dar um aviso de que nenhuma das mudanças no recurso um branch, o que realmente mais em qualquer outro branch. E, como você pode ver, o recurso de ramificação não está totalmente mesclado. Mas como ele sabe que esse ramo não foi mesclado? Ele dará uma olhada no último commit do branch do recurso um. E ele percebe que não há outro ramo apontando para esse commit. Get nos dá um aviso. Além disso, também está nos sugerindo se ainda queremos excluir esse branch, então podemos ir em frente e fazer isso com a opção hífen d. Isso é D maiúsculo comparado ao D minúsculo, que usamos anteriormente. E get realmente nos forneceu o comando padrão. Eu posso simplesmente colar aqui. E isso excluiria a ramificação. E, claro, perderemos todas as mudanças introduzidas no branch feature one. Quando excluímos esse branch, git realmente nos forneceu o HashCode do último commit apenas no caso de querermos fazer algo com ele. Agora vamos supor que eu tenha cometido um erro ao excluir esse branch e eu queria recuperá-lo de volta. O que é um comando que me ajudará a recuperar esse branch? Mais uma vez, você já está familiarizado com isso. Nós o usamos em uma de nossas palestras anteriores. Bem, é git, check hyphen b. E então você vai especificar um nome de branch. Podemos dar qualquer nome de nossa escolha. Mas eu vou fazer o mesmo nome, pizza um. Em seguida, especificaremos o HashCode do combate para o qual você deseja que esse ramo aponte. Essencialmente, o que esse comando está fazendo é não apenas criar o recurso de branch, mas também mudaremos para esse branch com o último commit sendo este commit com esse recurso HashCode, um branch seria criado, e esse branch estaria apontando para esse commit que acabamos de excluir. Se você executar esse comando depois de muito tempo, depois de excluir o branch, talvez não consiga mais ver esse commit e, na verdade, perderá os dados. Então, vamos recuperar esse ramo mais uma vez. E como você pode ver, nós mudamos para esse novo ramo. E se você fizer git log, poderá ver que o branch está apontando exatamente para o mesmo commit. Na verdade, a maneira certa de ver isso deu uma olhada no que está dentro do arquivo de ramificação do recurso um. E, como esperado, está apontando para esse commit. Agora podemos ir em frente e mesclar todas as alterações alternando de volta para o branch master. E isso é algo que já vimos em nossa palestra anterior. Git, mesclar recurso um. E isso anda. Agora você pode ir em frente e excluir esse branch com a opção d minúscula e não há nenhum problema. Vamos dar uma olhada na lista de filiais. E você verá que o único ramo que temos agora é o Mestre. 34. 0404 Entendendo três vias mescla e mescla commit: Vamos falar sobre fusão de três vias e obter. Digamos que esse seja o estado atual do nosso projeto. Temos o branch master com três commits, m1, m2 e m3. E também temos o branch feature com os commits F1, F2 e F3. E imagine que em cada um desses commits, entregamos um único arquivo. Por exemplo, no commit M1, entregamos m1 dot TXT. No commit M2, entregamos m2 dot TXT, assim por diante e assim por diante para todo o resto dos comentários. Agora, não vou manter os nomes dos arquivos neste diagrama apenas para mantê-lo limpo. Agora vamos supor que, enquanto estou trabalhando nas alterações do recurso um, tenho dois comentários adicionais e ramificação principal. Agora, uma pergunta para você, se eu decidir mesclar o recurso um no mestre agora, podemos esperar realizar a fusão de avanço rápido neste caso? A resposta é não, não será capaz de fazer isso. Ok, vamos supor hipoteticamente que bem fez uma fusão rápida. Portanto, agora temos a ramificação principal apontando para o recurso de confirmação mais recente, uma ramificação. Você consegue adivinhar o que vai acontecer? Bem, queríamos perder as mudanças introduzidas e os combatentes m four e m phi porque eles não se enquadram na hierarquia pai do commit para o qual o branch master está apontando. Isso não é uma coisa ideal a se fazer e o bem não executa a fusão de avanço rápido neste caso. O desempenho de TI, porém, é chamado de fusão de três vias. Então, o que essencialmente faz é quando decidimos mesclar o recurso um no branch master, entramos no branch master e pedimos ao get para realizar a mesclagem. E quando dizemos isso, o get criará artificialmente um commit com o que iniciamos. Esse commit terá dois pais. Em outras palavras, esse objeto commit apontaria para dois outros objetos comuns e esses comentários seriam os últimos comentários de ambas as ramificações, esse commit é chamado de merge commit. E o instantâneo resultante desse commit, a combinação de alterações introduzidas em ambas as ramificações. Essencialmente, se você quiser visualizar o diretório de trabalho do branch master depois de executar a mesclagem, você verá todas as alterações introduzidas em ambas as ramificações. Quando terminarmos a fusão, podemos seguir em frente e excluir o branch do recurso um. Observe que excluir o recurso um branch excluiria apenas esse branch, mas não os commits que estão no branch do recurso. Porque merge commit está se referindo a commit. Então branch recurso, então get não será capaz de excluir isso, são qualificados para coleta de lixo. Agora, o que estamos falando agora é o melhor cenário possível. Na maioria das vezes, temos os chamados conflitos de fusão. Por exemplo, se eu adicionei o mesmo arquivo em ambas as ramificações. E então, quando tentamos mesclar essas ramificações, get vai nos dizer que há conflito de mudanças em ambas as ramificações somente depois de resolvermos esse conflito de mesclagem. Bem, o git mescla todas as ramificações. Vou falar sobre conflitos de fusão nas próximas palestras. E você pode estar se perguntando por que isso é chamado de fusão de três vias. Bem, você também encontrará uma resposta para isso nas próximas palestras. Uma vez depois, falamos sobre os conflitos de fusão. Em seguida, vamos dar uma olhada em um exemplo de fusão de três vias, assumindo que não temos nenhum tipo de conflito. Vejo você na próxima. 35. 0405Três vias se mesclam em ação: A fim de explicar muito impulsionado no exterior o projeto para este estado. Inicialmente, comprometi M1, M2, M3 no branch master e, em seguida, criei o switch de branch de recurso para ele e fiz três comentários lá também. F1, F2 e F3. Mais uma vez voltei para master e fiz commits adicionais, M4, M5. E esse é o estado atual do nosso projeto. E sem mencionar que, para cada commit, eu confirmei seus arquivos específicos. Agora vamos ver o quanto é feito. Atualmente sou mestre interno. E assim você pode ver todos esses cinco arquivos correspondentes a todos esses cinco commits. Se eu fosse mudar para o recurso um ramo, você veria M1, M2, M3 e F1, F2 e F3, mas não m quatro e m phi, que vieram no branch master depois que criamos o branch feature one. E esta é a razão pela qual não podemos realizar a fusão de avanço rápido. Agora vamos voltar ao branch master e realizar a mesclagem e ver o que vai acontecer. Recurso um do Git Merge. E temos que fazer isso de dentro do branch master porque queremos trazer todos os recursos que um muda para o branch master. E quando eu executo esse comando, ele realmente abriu o editor de texto padrão que eu escolhi ao instalar o bem. No meu caso, é o Notepad Plus, Plus. No seu caso, pode ser outra coisa dependendo do que você escolheu ao instalar o Git. E o que está nos pedindo é inserir algum tipo de mensagem. Essa é a mensagem que seria associada ao commit de mesclagem. Eu posso mudar o texto para outra coisa em mestre, algo desse tipo. Salve o arquivo e feche a janela. E isso criou o commit de mesclagem. Como alternativa, ao executar esse comando, também posso fornecer a opção hyphen m e fornecer a mensagem. Dessa forma, o get não abrirá o editor de texto. Ok, agora vamos dar uma olhada em get log n z. Se Deus criou um commit de mesclagem. E com certeza, ele criou o commit de mesclagem. E também mencionou que esse comitê é baseado nesses dois compromissos. Estes não são nada além dos últimos cometas de ambos os ramos. Portanto, temos esse HashCode do branch master, e isso pertence ao branch feature. Vamos dar uma olhada no que está dentro desse objeto de commit de mesclagem. Então, vou copiá-lo. Vou pressionar Q para reverter para a linha de comando para que eu possa digitar alguns comandos. Git cat file, hífen b e hashCode do commit de mesclagem. E se você perceber que está apontando para esses dois commits. Um é o último commit, o branch master, que seria esse. E esse é o último ramo do recurso. Vamos dar uma olhada no que está dentro desse objeto de árvore. Vou usar exatamente o mesmo comando. E vamos ver o que está dentro desse objeto de árvore. E deixe-me expandir. Esse objeto de árvore é , na verdade, uma combinação de todas as alterações feitas nos dois ramos. Então você vê todos esses arquivos, ponto F1 TXT, depois de dxdy, F três, M1, M2, M3, M4 e M5. E mesmo no diretório de trabalho, agora você verá todas as mudanças do branch de recursos. Se você voltar para a ramificação de recurso, no entanto, notará que não há alterações feitas aqui. É exatamente o mesmo diretório de trabalho de antes, a hipoteca. Agora podemos realmente ir em frente e excluir o recurso de uma ramificação. Mas antes de tudo, vamos voltar para o branch master porque não podemos excluir o branch em que estamos atualmente. Então, vou usar o comando get. Eu vou dizer git branch hyphen D, recurso um. E isso excluiu a ramificação. 36. 0406 Entendendo conflitos: Vamos falar sobre conflitos de mesclagem e assumir que eu fiz um commit no branch master, vamos chamá-lo de M1. E como parte desse comentário, apresentei o produto de arquivo ponto TXT com algumas linhas de código. Agora, obviamente, não faz sentido escrever código e arquivo TXT de pontos. Você precisa assumir que isso é algum tipo de arquivo de origem, como o arquivo Java Python ou qualquer outra coisa. Agora também devo mencionar que normalmente nunca tendemos a fazer commits no branch master. O que geralmente temos no branch master, ou os chamados commits de mesclagem, que discutimos anteriormente. Quando falamos sobre repositório centralizado e colaboração em equipe. Você entenderá como todos criariam suas próprias ramificações para seguir seus próprios recursos e, em seguida, mesclar todas essas alterações na ramificação mestre no repositório centralizado. E então, quando atualizarmos localmente o projeto, colocaremos todos os commits de mesclagem feitos por outros membros da equipe em nosso branch master. Se isso parecer confuso, você terá que esperar até falarmos sobre repositório centralizado e colaboração em equipe. Por enquanto, para o bem deste exemplo, suponha que estamos fazendo commits no branch master. Eu fiz o commit M1, apresentando este produto de arquivo ponto TXT com algumas linhas de código. E então eu fiz outro commit, vamos chamá-lo de m2. Desta vez, atualizei o arquivo TXT de pontos do produto com mais algumas linhas de código. Vamos supor que agora eu decidi trabalhar em outro recurso. Adivinha? Vou criar uma ramificação de recursos, trabalhar nela, apresentar todas essas mudanças. E então vamos fazer um commit em que eu modifiquei o arquivo TXT de ponto do produto escrevendo algumas linhas adicionais de código que são relevantes para o recurso um. Enquanto isso, voltei para o branch master. Portanto, nosso arquivo de projeto se pareceria com isso porque o branch master está apontando para m para commit. E então vamos supor que eu fiz mais um branch master comprometido atualizando o arquivo TXT de ponto do produto, como você está vendo aqui. Agora, uma pergunta para você. Digamos que eu tenha decidido mesclar o branch feature no branch master. E eu executo o comando e consigo mesclar o branch. Você esperaria conseguir realizar a fusão? A resposta é não. Por quê? Porque temos algumas versões do arquivo TXT de ponto do produto. No branch master, temos produto ponto TXT que você está vendo à esquerda. E na ramificação do recurso, temos o arquivo que você está vendo à direita. Quando pedimos bem para mesclar, ele não pode manter os dois arquivos. Fique confuso quanto a quais dessas mudanças ele precisa manter ou precisa manter quaisquer alterações. Obviamente, não é inteligente o suficiente para fazer edições de acordo com nossas necessidades. Por isso, cabe a nós fazer todas as mudanças, resolver os conflitos. Só então vai realmente seguir em frente e executar a mesclagem e criar um commit de mesclagem. Essencialmente, quando você executa o comando para mesclar, ele lançará um erro dizendo que foi encontrado complexo em alguns dos arquivos. E somente depois de resolvê-los, ele irá em frente e mesclará as alterações e criará um commit de mesclagem? Agora, por que essa fusão é chamada de fusão de três vias? Você pode estar se perguntando, bem, é basicamente porque essa mesclagem envolve três instantâneos, os dois últimos comentários e o convecto que é um ancestral imediato de ambos os comentários. Esse colega, ele comparará o arquivo no instantâneo do ancestral imediato com os arquivos nos instantâneos mais recentes em ambas as ramificações. Agora, se você não entendeu, está tudo bem. Realmente não vale a pena saber disso. Para explicar isso. Bem, eu tenho que ir fundo e novamente, entrar nesses HashCode e tudo mais, o que eu não quero, porque não é de todo o que isso basta lembrar que esse tipo de modelo é chamado de fusão de três vias. E isso deve ser suficiente. E o modo de avanço rápido também é chamado de emergir porque envolve apenas alguns instantâneos. Em seguida, vamos dar uma olhada em tudo isso em ação e ver como podemos resolver os conflitos. 37. 0407 mescla conflitos na ação Parte 1: Tudo bem, vamos dar uma olhada em conflitos de fusão, inação. E para isso eu tenho uma nova pasta que atualmente não tem nada. Vamos fazer tudo do zero. Neste vídeo, tentaremos criar um cenário em que tenhamos conflitos. E então, no próximo vídeo, veremos como podemos resolver esses conflitos para poder mesclar as ramificações. Em primeiro lugar, vamos inicializar o projeto. Agora suponha que eu recebi um projeto de um dos clientes, enquanto pedi para criar um aplicativo de gerenciamento de produto. Dentro do projeto, posso estar tendo esses arquivos. Podemos ter um arquivo de produto que terá o código-fonte relacionado ao produto. E então podemos ter um arquivo de inventário e, em seguida, talvez um arquivo de administrador também. Agora, obviamente, esses arquivos não podem ser arquivos dot TXT. Você precisa fazer uma suposição de que esses são algum tipo de arquivo fonte como Java, python, Node.JS ou qualquer outra coisa. Agora vamos em frente e preencher algo nesse arquivo, simulando que estamos realmente escrevendo o código-fonte. Vamos começar com o arquivo txt do produto. Assim. Você precisa presumir que isso é na verdade, algum tipo de código-fonte. Salve o arquivo e feche-o. E eu vou fazer o mesmo para os outros dois arquivos também. Salve o arquivo e feche-o. Vamos fazer o mesmo com o arquivo admin. Salve e feche isso. Vamos preparar todos esses arquivos. Adicionar git. Vou usar caracteres curinga para preparar todos os arquivos. E vamos comprometer essas mudanças. Seja como for, alguma mensagem. Agora vamos supor que eu comecei a trabalhar em outro recurso. E então eu tenho que criar outro branch para trabalhar em todas essas mudanças relacionadas a recursos. Vou usar o comando git checkout hyphen b e, em seguida, o nome do branch. Portanto, esse comando criará um branch de recurso e alternará para ele. Portanto, estamos atualmente dentro da ramificação do recurso um. Vamos fazer algumas edições e o inventário desses dois arquivos, bem como o arquivo txt ponto do produto. Mas vamos deixar o arquivo TXT do ponto admin como está. Vou simplesmente adicionar mais algumas linhas de código. Mas vou dizer recurso no início dessas linhas, só para sabermos que essas linhas são introduzidas no ramo de recursos. Você sabe o propósito disso daqui a pouco. Vou fazer o mesmo para o arquivo txt de ponto de inventário. Assim, salve o arquivo e feche-o. Vamos encenar todas essas mudanças. Alguma mensagem e confirme todas as mudanças. Deixe-me voltar para o mestre mais uma vez. Vamos limpar a tela e tentar atualizar o arquivo TXT de ponto do produto. Mas deixe esses dois tamanhos de arquivo. Obviamente, não veremos todas essas mudanças relacionadas ao recurso aqui porque voltamos para o branch master. Vamos fechar o arquivo, preparar essas alterações e confirmar essas alterações. Assim. Então, apenas para reiterar o que fizemos, todos esses três arquivos não foram solicitados como estão antes de criar a ramificação. O arquivo de inventário é atualizado na ramificação de recurso, mas não na ramificação mestre desde que criamos a ramificação, mas o arquivo do produto foi modificado em ambas as ramificações. Agora você pode adivinhar quais desses arquivos terão conflitos? Quando tentamos mesclar, as alterações continuarão a partir do próximo vídeo. 38. 0408 mescla conflitos na ação Parte 2: Tudo isso. Vamos tentar realizar a fusão e ver o que aconteceria. Atualmente, estou dentro do branch master e quando executar o comando git merge feature one. Good diz que gerou conflitos no arquivo TXT do ponto do produto. E diz que a mesclagem automática falhou, corrige os conflitos e, em seguida, confirma o resultado. Isso é bastante autoexplicativo. Além disso, o gateway também está dizendo que nosso projeto está em estado de fusão. Na gestão do estado. O Git formatará todos esses arquivos conflitantes de uma maneira que se torne mais fácil para nós entender o complexo e resolvê-los. Você saberá o que quero dizer daqui a pouco. Mas vamos tentar executar o comando git status e ver o que ele tem a dizer. Diz que temos caminhos não mesclados. E está nos pedindo para consertar o complexo e, em seguida, executar o comando git commit. E se decidirmos sair desse estado de fusão? Podemos executar este comando com traço, traço , eu comprei a opção, este testamento eu comprei o estado emergente e trazer de volta o projeto como ele estava antes de executar o comando merge. Ele tem o arquivo TXT de ponto de inventário porque não tem nenhum conflito. Ele está pronto para ser mesclado. Mas enquanto para o arquivo TXT de ponto do produto, ele é categorizado em caminhos não mesclados. Portanto, todos os arquivos listados nesta seção, precisaremos resolver os conflitos e pedir ao get para confirmar todas essas alterações para concluir a operação de mesclagem e criar o commit de mesclagem. Agora vamos dar uma olhada no conteúdo do arquivo TXT de pontos do produto. Enquanto nosso projeto está em estado de fusão. Eu queria dizer arquivo TXT de ponto de produto cat. E você pode ver que é um pouco diferente do que você esperava. Você veria o mesmo mesmo se fosse abrir o arquivo em um editor externo. O que isso significa essencialmente é esta seção do código pertence a head, o que significa que essa chamada pertence ao ramo para o qual eles apontaram. Essas são as mudanças introduzidas na ramificação principal essencialmente. Em seguida, temos esse conjunto de mudanças que foram introduzidas na ramificação do recurso um. Se você comprou o estado emergente dizendo git merge hyphen, hífen comprado. Você veria que toda essa formatação desapareceu. E nosso projeto é essencial no estado como se nunca tivéssemos executado o comando merge. Vamos tentar nos fundir novamente e ver como podemos resolver esses conflitos. Agora, como programador, você tem que decidir qual dessas mudanças você gostaria de manter. Ou se você quiser manter essas duas mudanças, você pode ir em frente e fazer isso também. Você pode literalmente fazer a água que queremos fazer. E quando terminar, basta pedir ao get para confirmar essas alterações e criar o Merge Objects. Como terminar a fusão dos dois ramos. Então, eu preciso me livrar desses personagens estranhos que introduziram. E então talvez eu queira remover essa linha de código, mas fique com todas essas três. Só um exemplo. O que, oh, isso faz sentido. Você gostaria de manter esse código. Salve e feche. E depois de resolver todos esses complexos manualmente, você pode ir em frente e dizer git commit. Antes de entrarmos, precisamos realmente preparar este arquivo, arquivo TXT de ponto de produto. E então podemos ir em frente e com as mudanças está nos pedindo para inserir uma mensagem de confirmação. Estou feliz com o padrão. Eu queria salvar esse arquivo, fechá-lo. E isso criou com sucesso um commit de mesclagem, o que significa que nossa margem está concluída. E assim você não veria mais o status mais gene. Vamos agora dar uma olhada no conteúdo todos esses arquivos. O arquivo TXT do ponto admin permaneceria como está porque nunca é modificado em nenhuma das ramificações. De qualquer forma. No arquivo de inventário, você verá todas essas alterações de recursos adicionadas. E eles foram mesclados a partir da ramificação do recurso. Coloque no arquivo txt ponto do produto. Ele teria o código que atualizamos ao resolver os conflitos. Além disso, espero que você uma noção da necessidade de ter uma ferramenta mais robusta para gerenciar seu projeto e seus arquivos. E também ser capaz de visualizar todas as mudanças históricas, etc. E é aí que ferramentas como Visual Studio, Code, GitHub, Desktop, árvore de origem, etc., entrariam em cena. Vamos explorá-los nas próximas palestras. 39. 0409 Instalar e configurar o Visual Studio Code para trabalhar no Git: Ok, é hora de instalá-lo e usar uma das ferramentas disponíveis para nos ajudar a gerenciar nosso projeto de uma maneira melhor, porque não podemos simplesmente continuar usando o sistema de arquivos do Windows e o Git Bash para trabalhar em nosso projeto. À medida que um projeto se torna mais complexo, precisamos de algum tipo de ferramenta que nos ajude a gerenciar nosso projeto de uma maneira melhor e seja capaz de visualizar algumas das mudanças históricas ou lista de confirmações que fizemos. Dê uma olhada na lista de branches ao mesmo tempo, seja capaz de executar algumas das operações sem precisar executar comandos no Git Bash. Portanto, existem muitas ferramentas disponíveis on-line e não há uma ferramenta única que seja adequada para todo tipo de coisa. Se você for ao site oficial do gate, que é Git SCM.com, python SCM.com. E se você for para esta seção de linhas de grade, você verá que eles listaram estão recomendando todas essas ferramentas. Se você usa qualquer uma dessas ferramentas, não deve ser difícil para você usar qualquer uma das outras ferramentas disponíveis aqui. Porque, embora difiram em termos de interface gráfica do usuário, eles praticamente ofereceram exatamente a mesma funcionalidade. Github, desktop e árvore de origem, ou duas das opções mais populares. Mas vamos usar o Visual Studio Code. A razão pela qual estou recomendando isso é porque o Visual Studio Code é um dos editores de código populares. É uma das escolhas populares para desenvolver aplicativos JavaScript Python e tem suporte para várias outras linguagens de programação. Mas o que diferencia o código do Visual Studio de algumas dessas ferramentas é valioso aqui é que sua capacidade de instalar extensões. E é assim que vamos instalar uma boa extensão. E isso lhe dará alguns dos recursos oferecidos por algumas dessas ferramentas. Essas ferramentas aqui. O Visual Studio Code é mais uma ferramenta holística, em vez de apenas ter como objetivo obter especificamente. Quando você estiver acostumado a usar o Visual Studio Code, deve ser muito fácil entender algumas dessas ferramentas E portas. Se você quiser escolher uma dessas ferramentas, então você pode ir em frente e fazer isso se estiver confortável com isso. Mas vou usar o Visual Studio Code com uma rápida pesquisa no Google. Chegamos a esta página. Vá em frente e baixe o Visual Studio, dependendo do sistema operacional que você está usando. Eu já fiz isso. Deixe-me iniciar o instalador. A instalação é bem simples. Você pode simplesmente deixar tudo para o padrão, a menos que queira mudar alguma coisa. Ok, está instalado. Vamos lançar o Visual Studio Code. Em primeiro lugar, vamos ao Explorer e quando abrir o projeto clicando em Abrir pasta. Vou escolher meu aplicativo que criamos anteriormente. Além disso, vou para a seção chamada extensões. Eu procuraria por Get. Obter lentes é uma das escolhas populares. Obter gráfico também é uma boa escolha. Vamos instalá-lo. Tudo bem, no próximo vídeo, veremos como podemos lidar com conflitos de mesclagem no código do Visual Studio. Isso lhe dará alguma exposição ao Visual Studio Code, bem como às operações mob the get que podemos realizar nele. Vejo você no próximo. 40. 0410 Explorando o código de VS e realizando operações de GIT: Ok, antes de realmente darmos uma olhada em como criar conflitos de mesclagem e resolvê-los no código do Visual Studio. Deixe-me mostrar o estado atual do nosso projeto. Se você se lembra, mesclamos nossas alterações do recurso um para o branch master. Essas são todas as listas de arquivos em nosso projeto. Basta clicar neles para dar uma olhada no conteúdo deles. E se você for para esta seção controle de origem, você também pode ir lá pressionando Control Shift G. E como instalamos essa extensão bom gráfico, você deve ser capaz de olhar para este ícone. Aqui você pode ver todas as mudanças históricas que introduzimos. Você também pode ver a representação gráfica de toda a lista de commits que fizemos, as ramificações que criamos e até mesmo a mesclagem que realizamos anteriormente. Este é o primeiro commit que fizemos no branch master e, em seguida, criamos um branch de recurso. Fizemos um comentário lá. E então fizemos um comentário e branch master e , eventualmente feature branches mesclados dentro do branch master. Para criar o comando merge. Ele não clicou em um desses commits e deu uma olhada nas mudanças introduzidas naquele commit específico clicando em um arquivo específico. E você pode ver as mudanças. Agora vamos em frente e criar conflitos nos quais nós, humanos, somos naturalmente bons. Vamos voltar ao Explorer. Mas antes disso, vamos ver como podemos criar uma nova ramificação. Vou criar uma nova filial aqui. Então, vou clicar com o botão direito nesse commit específico e dizer Create Branch. Vamos chamá-lo de recurso para ramificar, seja o que for. E eu também gostaria de mudar para esse ramo. Então eu marquei esta caixa de seleção criar ramificação. Então, mudamos para esse recurso para o branch que acabamos de criar. Você pode dizer isso dando uma olhada aqui. Aqui você pode ver toda a lista de filiais. Depois de clicar nele, você pode ver toda a lista de filiais. Se você quiser mudar para uma das ramificações, basta clicar nela. Então, nós só queremos dominar o ramo. E é isso que você está vendo aqui. Deixe-me voltar para o branch do recurso dois e fazer um commit. Eu vou para o Explorer. Deixe-me apenas fazer algumas edições e recurso de arquivo de inventário para alterações no arquivo de inventário ou qualquer outra coisa. Eu vou voltar para esta seção controle de origem. Vou clicar nesse ícone de verificação. Ao fazer isso. Ele está me mostrando uma mensagem dizendo que não há mudanças encenadas por vir. Você gostaria de organizar todas as mudanças e comprometê-las diretamente? Se eu acertar sim, agora mesmo, vai encenar as mudanças antes me comprometer sem que eu precise fazer isso. Ou se você quiser fazer isso sozinho, você também pode fazer isso. Basta clicar com o botão direito do mouse neste arquivo que está atualmente na categoria de alterações. Em seguida, clique em mudanças de palco. Isso moveria esse arquivo para a categoria de alterações em estágios. E agora, se você chegar lá , você não deve ter nenhum problema ou algo assim. Mas vamos inserir algum tipo de mensagem de commit. Tanto faz. Clique neste ícone e acabei de fazer um novo commit e apresentar duas ramificações. Vamos dar uma olhada no gráfico. E como você pode ver, agora temos um novo commit adicionado no gráfico. E aqui está. Agora vamos voltar para o branch master. Vamos fazer edições nesse mesmo arquivo de inventário. Então, para criar conflitos, salve o arquivo. Volte aqui. Desta vez. Vamos apertar o S. Se você não quiser ver esse prompt novamente, basta pressionar nunca. Vamos voltar para obter o gráfico mais uma vez. E como você pode ver, agora temos um novo commit e branch master. Agora vamos tentar realizar a fusão. Como desempenhamos muito no Visual Studio Code? Mas essa extensão, bem, é bem fácil. Basta clicar com o botão direito do mouse em um dos galhos. Vou clicar no recurso para ramificar. E você pode escolher essa opção que diz mesclar na ramificação atual. Qual é a ramificação atual, ou seja, máscara? Bem, é simplesmente o ramo que tinha isso apontando. Em outras palavras, é o ramo principal. Vamos clicar nele e ver o que acontece. Ele está nos perguntando se queremos criar um novo commit, mesmo que a mesclagem rápida seja possível? Eu não gosto de responder. Sim, mesclar. Como esperado, temos um inventor de fusão automática de conflito ou dxdy. E então diz que temos um conflito. Descarte-o, vá para o Explorer, vá para esse arquivo. E desta vez ele tem formato nós dessa maneira, assim como antes. Mas usamos hoje Deus nos deu poucas opções. Se você notar, aceite as alterações atuais, aceite as alterações recebidas ou as alterações que estão chegando do recurso para a ramificação, para a ramificação mestre. Ou aceite as duas alterações. Ou você também pode comparar as mudanças. Você pode escolher. Qualquer uma dessas opções é se você quiser fazer sua própria edição, você possa fazer isso também. Basta excluir tudo e trazer suas próprias alterações ou editar a existente. Tanto faz. Vamos adicionar como manter as duas alterações ou clicar aqui que diz aceitar as alterações. Agora salve o arquivo. Volte para o controle de origem. Antes de cometermos isso. Vamos encenar essas mudanças são bastante encenadas. Vamos clicar nessa caixa de seleção. Estou feliz com a mensagem existente. E adivinha? Isso acabou de criar o commit de mesclagem. Agora, se você estiver usando uma ferramenta diferente, não o Visual Studio Code, então você deve ser capaz de analisar todas essas operações de uma forma ou de outra. Somente a interface gráfica do usuário pode mudar. Mas em todas essas ferramentas, você pode realizar praticamente o mesmo conjunto de operações. Por exemplo, se você for ao site oficial da árvore de origem, basta dar uma olhada nessa imagem, você pode dizer muito. Portanto, temos uma história que mostra as mudanças históricas. Você também tem esse gráfico, assim como o que temos no Visual Studio Code. Você também pode ir para esta seção de branches para dar uma olhada nos branches e fazer algo com isso, como criá-los, excluí-los, etc. Você também pode realizar confirmações. E algumas das outras operações que não exploramos. Vamos explorar as próximas palestras com certeza. Mas espero que você tenha entendido. Não importa qual ferramenta você usa. Em última análise, cada ferramenta tem o mesmo propósito, que é simplificar seu trabalho. Agora acho que podemos excluir esse branch. Não precisaríamos mais disso. Então, vou clicar com o botão direito nesse branch e dizer Delete branch. Pode fazer o mesmo recurso, um ramo também. E, claro, a marca líder não exclui seus commits. Como discutimos antes. Espero que faça sentido, certo? Para fazer o que acabei de fazer no Visual Studio Code e ter uma ideia de como tudo está funcionando. E não se deixe intimidar olhando para essa ferramenta. É bem simples. A ferramenta é simplesmente como um editor de texto com alguns recursos muito legais. Está lá para tornar nossa vida mais fácil, não mais difícil. Vejo você no próximo. 41. 0411 Git Rebase vs Merge: Vamos falar sobre git rebase. O rebase do Git é como uma alternativa para mesclar. Ele serve praticamente ao mesmo propósito operação de mesclagem. Mas dito isso, você não pode substituir um pelo outro. Não podemos substituir o VBS pela mesclagem e vice-versa, não podemos substituir a mesclagem pelo rebase. Ele tem seus próprios prós e contras e cada um tem seu próprio propósito. E é sobre isso que vamos falar nesta palestra e nas próximas palestras. Em primeiro lugar, vamos tentar entender o que exatamente é rebase. No caso de mesclagem de três vias, GET solicita a criação de um commit de mesclagem cujo instantâneo constituiria as alterações de ambas as ramificações. Embora isso não pareça um problema, começamos a ver alguns problemas com isso, especialmente quando nosso projeto fica cada vez maior. Em primeiro lugar, a mesclagem criaria esse commit de mesclagem adicional, o que pode ser desnecessário. Em segundo lugar, ele cria o problema do chamado histórico de commits de espaguete. Se você executar muitas operações de mesclagem em seu projeto. É assim que o histórico do nosso projeto pode parecer. Agora, se você fosse dar uma olhada em todos os commits históricos feitos, talvez digamos que você tenha executado comando git log no branch master. Tudo o que você vai ver é um monte de commits de mesclagem. Você não consegue ver as mudanças introduzidas em ramificações individuais. Você precisa navegar pela hierarquia pai para poder ver todas as alterações ou comentários relacionados ao branch. Isso vai criar muita confusão. Rebus put meio que resolve esses problemas que vemos com os commits de mesclagem. Para entender como os descontos funcionam exatamente, vamos supor que não realizamos a fusão dessas duas ramificações. E esse é o estado atual do nosso projeto. Agora vamos supor que estou no recurso um branch e executei o comando git rebase. O que o bem faria agora é, antes de tudo, tentar encontrar o ancestral comum de ambos os ramos, que neste caso é o commit N3. E, em seguida, ele armazenará temporariamente todas essas alterações introduzidas no recurso um. Em algum lugar no repositório. Em seguida, ele apontaria o recurso um branch para a ponta do branch master, que neste caso é m phi commit. O Git reaplicará todos os commits armazenados um por um. É assim que criamos o branch AT MY commit e introduzimos todos esses recursos que levam a mudanças no branch do recurso. Anteriormente, nosso recurso se ramifica com base no commit M3. Agora, depois de executar o comando rebase, ele agora é rebaseado para m phi. Agora, ao fazer essa operação, você também pode ver conflitos. Podemos resolvê-los da mesma forma que resolvemos conflitos em caso de operação de fusão. Fomos ver um exemplo disso nas próximas palestras. Agora, se você der uma olhada neste diagrama, você percebe que podemos realmente realizar mesclagem de avanço rápido dessa forma. Agora adivinhe? Nenhum comentário adicional foi introduzido. Um allo commits é linear com a operação de mesclagem. Se você teve esse problema de histórico de commits de espaguete com rebase, temos um desenvolvimento linear como você está vendo aqui, o que torna mais fácil para nós dar uma olhada no histórico de commits. E se você fosse executar o comando git log agora, você não só verá como as alterações introduzidas no branch master, mas também todos os comentários relacionados ao recurso também forma linear. Agora você pode estar pensando que podemos começar a usar o rebase e nunca mais precisaríamos usar o merge. Você pode estar errado. Existem certos cenários em que rebase é a coisa ideal a se fazer, e há outro conjunto de cenários em que muito é uma opção melhor. Você entenderá mais sobre isso A seguir. 42. 0412 realizando rebase no código de VS: Tudo bem, vamos dar uma olhada em um exemplo de git rebase. Mas antes disso, deixe-me orientá-lo sobre o estado atual do nosso projeto. Na verdade, criei um projeto totalmente novo para esse propósito e fiz vários commits. Deixe-me explicar o que exatamente eu fiz. Desde o branch master como parte do primeiro commit, acabei de introduzir esses arquivos TXT, inventário administrativo e arquivos TXT de ponto de produto. E em cada um desses arquivos, acabei de adicionar algumas linhas de texto como se tivéssemos escrito algum código. O próximo commit foi dentro do mestre também. E antes disso, é claro que criei uma ramificação baseada no primeiro commit. Como parte do segundo commit, como a mensagem nos sugere, admin Edita e master. Acabei de adicionar uma linha de texto dentro do arquivo TXT do ponto admin, assim. E então eu fiz meu primeiro commit no branch do recurso e a mensagem sugere edições de inventário do branch do recurso um. Acabei de adicionar uma linha de texto dentro do arquivo inventado ou TXT. Da próxima vez que fizer commit no branch master. E desta vez eu adicionei uma linha de texto no arquivo TXT de pontos do produto. E então fiz mais um comentário na ramificação de recursos onde editei o arquivo TXT de ponto do produto. Abaixo da linha. Quando realizarmos o rebase, teremos conflitos no arquivo TXT do ponto do produto porque temos um commit feito no master onde editamos o arquivo TXT do ponto do produto, e o mesmo é feito no branch de recurso também. Da próxima vez fiz mais um branch master comprometido. Bem, isso não é realmente necessário para eu explicar isso, mas eu fiz esse comentário apenas para que o gráfico tenha a aparência que queremos. Basicamente, atualmente, essa linha azul está representando a ramificação mestre, enquanto a linha vermelha representa a ramificação do recurso. No entanto, isso pode não ser sempre o caso. Seja qual for o branch que fizermos o commit mais recente que seria mostrado primeiro. Por exemplo, se eu fizesse mais um branch de recurso de comentário, branch de recurso ficaria azul e o branch master ficaria vermelho. Pode parecer confuso. E é por isso que adicionei esse commit adicional para que o branch master apareça primeiro e depois o branch do recurso. Agora, antes de prosseguirmos, é muito importante que você entenda exatamente o que está acontecendo e quais são todas as mudanças que introduzimos em cada um desses commits. Então, vou disponibilizar esse projeto para você baixar. Você pode simplesmente importá-lo para código do Visual Studio e dar uma olhada em toda a lista de alterações, entendê-la e só então continuar. Caso contrário, você começará a se confundir. Se você for capaz de acompanhar, isso é ótimo. Se não estiver, faça uma pausa, entenda o que está acontecendo aqui e continue assistindo. Então, como você pode ver, o branch feature one está atualmente baseado no primeiro commit no branch master. Agora queremos fazer o rebase do branch do recurso um para o branch master de commit off mais recente. Como fazemos isso? Bem, vamos clicar com o botão direito do mouse no commit mais recente, o branch master. E então temos essa opção chamada rebase current branch neste commit. A ramificação atual é a ramificação mestre. Quando mudar para a ramificação do recurso. E sabemos que pressionamos para destacar um ramo porque esse círculo aqui está apontando para um ramo anterior, ele estava apontando para o ramo mestre. Agora vamos clicar com o botão direito do mouse no último commit off master branch e escolher esta opção que diz rebase current branch. Com isso, as ramificações atuais apresentam uma ramificação. E, idealmente, isso deve ser rebase, a menos que tenhamos conflitos. Obviamente, veremos conflitos porque, como mencionei antes, editamos o arquivo TXT de ponto do produto em ambas as ramificações. Então, vamos clicar em rebase. Como você pode ver, temos conflitos. Vamos descartar isso. Bem, idealmente deveríamos ver esses arquivos com complexo, deixe-me atualizar. E aí está. Você pode resolver os conflitos e da maneira que quiser. No meu caso, eu só quero aceitar as duas mudanças. Salve o arquivo. E então eu vou pressionar este ícone de adição para preparar este arquivo. E então eu posso clicar neste ícone de verificação para realmente prosseguir com a operação de rebase. E a mensagem que é preenchida por padrão aqui é a mensagem do recurso de comentários, uma ramificação que está realmente criando o conflito. Abrimos esse editor. Mas vou deixar a mensagem como está, fechar o arquivo. E isso deve terminar a operação de rebase. Como você pode ver, os primeiros quatro commits estão fora branch master e os outros dois comentários pertencem ao branch feature. Agora podemos seguir em frente e realizar a Marcha Avançada Rápida. Então, vou voltar para o branch master. Clique com o botão direito neste commit. E então eu posso escolher mesclar na ramificação atual. Então, eu quero mesclar o recurso um branch no branch master. Não quero criar um novo commit para mesclagem rápida. Então é assim que você executa o rebase. E se você notar, temos esse desenvolvimento linear, que é o que esperamos com rebase. Vejo você em seguida. 43. 0413 Git Rebase no Git Bash Skipping conflitos e Abortando o Rebase: Tudo bem, vamos ver como podemos realizar git rebase a partir do Git Bash. Atualmente, estamos no branch master para mudar para o recurso um branch para poder executar esse comando. E, a propósito, trouxemos de volta o projeto ao que parecia no início do nosso vídeo anterior. Para que possamos refazer as coisas e ver como funciona a partir do Git Bash. Vou mudar para o branch de recursos. Ele pode observar simultaneamente o que está acontecendo neste gráfico. Rebase do Git. Onde eu quero rebase para fazer um commit? Esse ramo mestre está apontando para alguém dizer Mestre. E como você pode esperar, vamos ver os conflitos. Vamos em frente e dissolvê-los. No meu palpite, mais uma vez, eu não aceitaria as duas alterações, salvaria o arquivo e voltaria ao Git Bash, fui para o estágio desse arquivo, git add product dot TXT file. E então precisamos executar esse comando. O rebase, o hífen e o hífen do Git continuam a executar o rebase. E eu vou fazer exatamente isso. Você também tem a opção de pular. Se você executar esse comando, o git simplesmente ignorará o commit que está causando os conflitos. É como se você não tivesse feito a ramificação do recurso de comentários que está causando os conflitos. Se você executar esse comando, talvez depois de executar com êxito o rebase, convém reaplicar todas essas alterações manualmente. No entanto, como resolvemos o complexo, você não precisa usar essa opção, mas sinta-se à vontade para experimentá-la. Depois de executar esse comando. Novamente, ele vai nos mostrar a mensagem. Podemos mantê-lo como está. Ou, se você quiser alterá-lo, você pode ir em frente e alterá-lo. Vamos fechar. E como você pode ver aqui, nós reformulamos nosso branch de recurso com o branch master. Vamos agora seguir em frente e executar a parte de mesclagem, que vamos voltar para o master git recurso master git merge um. E como você pode ver, os dois ramos são combinados. Se um bone do comando git log agora, você verá todos os commits introduzidos em ambas as ramificações de forma linear, que é o que precisamos. E, a propósito, operação de rebase com bom desempenho. E por algum motivo você decidiu abortá-lo, então você pode usar esta opção, git rebase, hífen, hífen que comprei. Vejo você em seguida. 44. 0414 Git Interactive Rebase: Segure isso, vamos falar sobre rebase interativo. E para isso eu tenho 1 segundo trazido de volta o projeto para o que era antes. Antes de realizar a operação de rebase. Deixe-me mudar para o recurso um branch e realizar o rebase. Eu quero clicar com o botão direito do mouse no último commit off Master, clique em rebase current branch neste comentário. Mas desta vez vou escolher essa opção que diz rebase interativa loira no novo terminal. Isso é equivalente a executar o comando git rebase com dash, dash interact to option. Vamos clicar em yes rebase. E desta vez abriremos o editor de texto. Aqui você verá a lista de titulares de commits que fazem parte do branch feature one. O que o rebase interativo nos permitiria fazer é que podemos realmente realizar muitas personalizações com base em nossas necessidades. Se você ver que temos vários comandos aqui, que podemos usar para dizer ao git o que queremos fazer com os commits ou apresentar um branch. Por padrão, esse comando é usado pick, o que significa que queremos usar esse comitê. O que isso significa essencialmente é que queremos que esses cometas do ramo feature one sejam candidatos para a operação de rebase. Mas você pode alterar esse comando para outra coisa com base em suas necessidades. Por exemplo, talvez eu queira usar essa recompensa de comando, que significa usar commit, mas adicionei a mensagem de commit. Essencialmente, se você quiser alterar a mensagem para outra coisa, então você pode usar esse comando. Vamos, eu quero mudar a mensagem desse comitê em particular. E vamos fazer isso. Eu gostaria de usar esse comando drop. Para descartar esse commit em particular. Eu sei que esse comentário vai criar conflitos porque editamos o arquivo txt do produto neste commit. Então, eu vou largar isso. Da mesma forma, você tem vários outros comandos que você pode usar. Você pode simplesmente passar pela descrição e ver se eles atendem às suas necessidades. Salve o arquivo e feche-o. Então, veremos outro prompt nos pedindo para encadear a mensagem desse commit. Se você se lembra do commit em particular, usamos a recompensa de comando. É aí que eu recebo isso nos levando a encadear a mensagem a outra coisa. Você pode mudar isso para o que quiser. Claro, não diga blá, blá, digite algo significativo. Quero salvar o arquivo e fechá-lo. Então, desta vez, se você notar, temos apenas cinco commits. Porque soltamos um dos commits no branch de recurso, onde fizemos alterações no arquivo TXT de ponto do produto. E também para o outro recurso de comentários, um ramo mudaria a mensagem para blá, blá. Então vá em frente e experimente com rebase interativo. Vejo você em seguida. 45. 0501 Git Rebase vs Merge: Vamos falar sobre git rebase. O rebase do Git é como uma alternativa para mesclar. Ele serve praticamente ao mesmo propósito operação de mesclagem. Mas dito isso, você não pode substituir um pelo outro. Não podemos substituir o VBS pela mesclagem e vice-versa, não podemos substituir a mesclagem pelo rebase. Ele tem seus próprios prós e contras e cada um tem seu próprio propósito. E é sobre isso que vamos falar nesta palestra e nas próximas palestras. Em primeiro lugar, vamos tentar entender o que exatamente é rebase. No caso de mesclagem de três vias, GET solicita a criação de um commit de mesclagem cujo instantâneo constituiria as alterações de ambas as ramificações. Embora isso não pareça um problema, começamos a ver alguns problemas com isso, especialmente quando nosso projeto fica cada vez maior. Em primeiro lugar, a mesclagem criaria esse commit de mesclagem adicional, o que pode ser desnecessário. Em segundo lugar, ele cria o problema do chamado histórico de commits de espaguete. Se você executar muitas operações de mesclagem em seu projeto. É assim que o histórico do nosso projeto pode parecer. Agora, se você fosse dar uma olhada em todos os commits históricos feitos, talvez digamos que você tenha executado comando git log no branch master. Tudo o que você vai ver é um monte de commits de mesclagem. Você não consegue ver as mudanças introduzidas em ramificações individuais. Você precisa navegar pela hierarquia pai para poder ver todas as alterações ou comentários relacionados ao branch. Isso vai criar muita confusão. Rebus put meio que resolve esses problemas que vemos com os commits de mesclagem. Para entender como os descontos funcionam exatamente, vamos supor que não realizamos a fusão dessas duas ramificações. E esse é o estado atual do nosso projeto. Agora vamos supor que estou no recurso um branch e executei o comando git rebase. O que o bem faria agora é, antes de tudo, tentar encontrar o ancestral comum de ambos os ramos, que neste caso é o commit N3. E, em seguida, ele armazenará temporariamente todas essas alterações introduzidas no recurso um. Em algum lugar no repositório. Em seguida, ele apontaria o recurso um branch para a ponta do branch master, que neste caso é m phi commit. O Git reaplicará todos os commits armazenados um por um. É assim que criamos o branch AT MY commit e introduzimos todos esses recursos que levam a mudanças no branch do recurso. Anteriormente, nosso recurso se ramifica com base no commit M3. Agora, depois de executar o comando rebase, ele agora é rebaseado para m phi. Agora, ao fazer essa operação, você também pode ver conflitos. Podemos resolvê-los da mesma forma que resolvemos conflitos em caso de operação de fusão. Fomos ver um exemplo disso nas próximas palestras. Agora, se você der uma olhada neste diagrama, você percebe que podemos realmente realizar mesclagem de avanço rápido dessa forma. Agora adivinhe? Nenhum comentário adicional foi introduzido. Um allo commits é linear com a operação de mesclagem. Se você teve esse problema de histórico de commits de espaguete com rebase, temos um desenvolvimento linear como você está vendo aqui, o que torna mais fácil para nós dar uma olhada no histórico de commits. E se você fosse executar o comando git log agora, você não só verá como as alterações introduzidas no branch master, mas também todos os comentários relacionados ao recurso também forma linear. Agora você pode estar pensando que podemos começar a usar o rebase e nunca mais precisaríamos usar o merge. Você pode estar errado. Existem certos cenários em que rebase é a coisa ideal a se fazer, e há outro conjunto de cenários em que muito é uma opção melhor. Você entenderá mais sobre isso A seguir. 46. 0502 realizando rebase em conflitos de código e manipulação de VS: Tudo bem, vamos dar uma olhada em um exemplo de git rebase. Mas antes disso, deixe-me orientá-lo sobre o estado atual do nosso projeto. Na verdade, criei um projeto totalmente novo para esse propósito e fiz vários commits. Deixe-me explicar o que exatamente eu fiz. Desde o branch master como parte do primeiro commit, acabei de introduzir esses arquivos TXT, inventário administrativo e arquivos TXT de ponto de produto. E em cada um desses arquivos, acabei de adicionar algumas linhas de texto como se tivéssemos escrito algum código. O próximo commit foi dentro do mestre também. E antes disso, é claro que criei uma ramificação baseada no primeiro commit. Como parte do segundo commit, como a mensagem nos sugere, admin Edita e master. Acabei de adicionar uma linha de texto dentro do arquivo TXT do ponto admin, assim. E então eu fiz meu primeiro commit no branch do recurso e a mensagem sugere edições de inventário do branch do recurso um. Acabei de adicionar uma linha de texto dentro do arquivo inventado ou TXT. Da próxima vez que fizer commit no branch master. E desta vez eu adicionei uma linha de texto no arquivo TXT de pontos do produto. E então fiz mais um comentário na ramificação de recursos onde editei o arquivo TXT de ponto do produto. Abaixo da linha. Quando realizarmos o rebase, teremos conflitos no arquivo TXT do ponto do produto porque temos um commit feito no master onde editamos o arquivo TXT do ponto do produto, e o mesmo é feito no branch de recurso também. Da próxima vez fiz mais um branch master comprometido. Bem, isso não é realmente necessário para eu explicar isso, mas eu fiz esse comentário apenas para que o gráfico tenha a aparência que queremos. Basicamente, atualmente, essa linha azul está representando a ramificação mestre, enquanto a linha vermelha representa a ramificação do recurso. No entanto, isso pode não ser sempre o caso. Seja qual for o branch que fizermos o commit mais recente que seria mostrado primeiro. Por exemplo, se eu fizesse mais um branch de recurso de comentário, branch de recurso ficaria azul e o branch master ficaria vermelho. Pode parecer confuso. E é por isso que adicionei esse commit adicional para que o branch master apareça primeiro e depois o branch do recurso. Agora, antes de prosseguirmos, é muito importante que você entenda exatamente o que está acontecendo e quais são todas as mudanças que introduzimos em cada um desses commits. Então, vou disponibilizar esse projeto para você baixar. Você pode simplesmente importá-lo para código do Visual Studio e dar uma olhada em toda a lista de alterações, entendê-la e só então continuar. Caso contrário, você começará a se confundir. Se você for capaz de acompanhar, isso é ótimo. Se não estiver, faça uma pausa, entenda o que está acontecendo aqui e continue assistindo. Então, como você pode ver, o branch feature one está atualmente baseado no primeiro commit no branch master. Agora queremos fazer o rebase do branch do recurso um para o branch master de commit off mais recente. Como fazemos isso? Bem, vamos clicar com o botão direito do mouse no commit mais recente, o branch master. E então temos essa opção chamada rebase current branch neste commit. A ramificação atual é a ramificação mestre. Quando mudar para a ramificação do recurso. E sabemos que pressionamos para destacar um ramo porque esse círculo aqui está apontando para um ramo anterior, ele estava apontando para o ramo mestre. Agora vamos clicar com o botão direito do mouse no último commit off master branch e escolher esta opção que diz rebase current branch. Com isso, as ramificações atuais apresentam uma ramificação. E, idealmente, isso deve ser rebase, a menos que tenhamos conflitos. Obviamente, veremos conflitos porque, como mencionei antes, editamos o arquivo TXT de ponto do produto em ambas as ramificações. Então, vamos clicar em rebase. Como você pode ver, temos conflitos. Vamos descartar isso. Bem, idealmente deveríamos ver esses arquivos com complexo, deixe-me atualizar. E aí está. Você pode resolver os conflitos e da maneira que quiser. No meu caso, eu só quero aceitar as duas mudanças. Salve o arquivo. E então eu vou pressionar este ícone de adição para preparar este arquivo. E então eu posso clicar neste ícone de verificação para realmente prosseguir com a operação de rebase. E a mensagem que é preenchida por padrão aqui é a mensagem do recurso de comentários, uma ramificação que está realmente criando o conflito. Abrimos esse editor. Mas vou deixar a mensagem como está, fechar o arquivo. E isso deve terminar a operação de rebase. Como você pode ver, os primeiros quatro commits estão fora branch master e os outros dois comentários pertencem ao branch feature. Agora podemos seguir em frente e realizar a Marcha Avançada Rápida. Então, vou voltar para o branch master. Clique com o botão direito neste commit. E então eu posso escolher mesclar na ramificação atual. Então, eu quero mesclar o recurso um branch no branch master. Não quero criar um novo commit para mesclagem rápida. Então é assim que você executa o rebase. E se você notar, temos esse desenvolvimento linear, que é o que esperamos com rebase. Vejo você em seguida. 47. 0503 Git Rebase no Git Bash Skipping conflitos e Abortando o Rebase: Tudo bem, vamos ver como podemos realizar git rebase a partir do Git Bash. Atualmente, estamos no branch master para mudar para o recurso um branch para poder executar esse comando. E, a propósito, trouxemos de volta o projeto ao que parecia no início do nosso vídeo anterior. Para que possamos refazer as coisas e ver como funciona a partir do Git Bash. Vou mudar para o branch de recursos. Ele pode observar simultaneamente o que está acontecendo neste gráfico. Rebase do Git. Onde eu quero rebase para fazer um commit? Esse ramo mestre está apontando para alguém dizer Mestre. E como você pode esperar, vamos ver os conflitos. Vamos em frente e dissolvê-los. No meu palpite, mais uma vez, eu não aceitaria as duas alterações, salvaria o arquivo e voltaria ao Git Bash, fui para o estágio desse arquivo, git add product dot TXT file. E então precisamos executar esse comando. O rebase, o hífen e o hífen do Git continuam a executar o rebase. E eu vou fazer exatamente isso. Você também tem a opção de pular. Se você executar esse comando, o git simplesmente ignorará o commit que está causando os conflitos. É como se você não tivesse feito a ramificação do recurso de comentários que está causando os conflitos. Se você executar esse comando, talvez depois de executar com êxito o rebase, convém reaplicar todas essas alterações manualmente. No entanto, como resolvemos o complexo, você não precisa usar essa opção, mas sinta-se à vontade para experimentá-la. Depois de executar esse comando. Novamente, ele vai nos mostrar a mensagem. Podemos mantê-lo como está. Ou, se você quiser alterá-lo, pode ir em frente e alterá-lo. Vamos fechar. E como você pode ver aqui, reformulamos nosso branch de recurso com o branch master. Vamos agora seguir em frente e executar a parte de mesclagem, que vamos voltar para o master git recurso master git merge um. E como você pode ver, os dois ramos são combinados. Se um bone do comando git log agora, você verá todos os commits introduzidos em ambas as ramificações de forma linear, que é o que precisamos. E, a propósito, operação de rebase com bom desempenho. E por algum motivo você decidiu abortá-lo, então você pode usar esta opção, git rebase, hífen, hífen que comprei. Vejo você em seguida. 48. 0504 Git Interactive Rebase: Segure isso, vamos falar sobre rebase interativo. E para isso eu tenho 1 segundo trazido de volta o projeto para o que era antes. Antes de realizar a operação de rebase. Deixe-me mudar para o recurso um branch e realizar o rebase. Eu quero clicar com o botão direito do mouse no último commit off Master, clique em rebase current branch neste comentário. Mas desta vez vou escolher essa opção que diz rebase interativa loira no novo terminal. Isso é equivalente a executar o comando git rebase com dash, dash interact to option. Vamos clicar em yes rebase. E desta vez abriremos o editor de texto. Aqui você verá a lista de titulares de commits que fazem parte do branch feature one. O que o rebase interativo nos permitiria fazer é que podemos realmente realizar muitas personalizações com base em nossas necessidades. Se você ver que temos vários comandos aqui, que podemos usar para dizer ao git o que queremos fazer com os commits ou apresentar um branch. Por padrão, esse comando é usado pick, o que significa que queremos usar esse comitê. O que isso significa essencialmente é que queremos que esses cometas do ramo feature one sejam candidatos para a operação de rebase. Mas você pode alterar esse comando para outra coisa com base em suas necessidades. Por exemplo, talvez eu queira usar essa recompensa de comando, que significa usar commit, mas adicionei a mensagem de commit. Essencialmente, se você quiser alterar a mensagem para outra coisa, então você pode usar esse comando. Vamos, eu quero mudar a mensagem desse comitê em particular. E vamos fazer isso. Eu gostaria de usar esse comando drop. Para descartar esse commit em particular. Eu sei que esse comentário vai criar conflitos porque editamos o arquivo txt do produto neste commit. Então eu vou largar isso. Da mesma forma, você tem vários outros comandos que você pode usar. Você pode simplesmente passar pela descrição e ver se eles atendem às suas necessidades. Salve o arquivo e feche-o. Então, veremos outro prompt nos pedindo para encadear a mensagem desse commit. Se você se lembra do commit em particular, usamos a recompensa de comando. É aí que eu recebo isso nos levando a encadear a mensagem a outra coisa. Você pode mudar isso para o que quiser. Claro, não diga blá, blá, digite algo significativo. Quero salvar o arquivo e fechá-lo. Então, desta vez, se você notar, temos apenas cinco commits. Porque soltamos um dos commits no branch de recurso, onde fizemos alterações no arquivo TXT de ponto do produto. E também para o outro recurso de comentários, um ramo mudaria a mensagem para blá, blá. Então vá em frente e experimente com rebase interativo. Vejo você em seguida. 49. 0505 Rebase para commit específico ou para outro ramo de recursos: Neste vídeo, vamos dar uma olhada em como podemos rebase para um compromisso específico. Não precisamos necessariamente rebase até a ponta de um galho. Também podemos fazer base para um commit específico. Atualmente, ou feature one branch é baseado no primeiro commit do branch master, mas eu posso rebaseá-lo para o segundo commit off branch master. No Visual Studio Code, preciso mudar para esse branch, que eu quero rebase. Eu escolho o recurso um ramo. Depois de fazer isso, vou clicar com o botão direito do mouse no commit onde gostaria reconstruir o recurso um ramo dois. E então eu posso escolher essa opção que diz rebase current branch neste commit. Se você fizesse o mesmo a partir do Git Bash aqui para agilizar o twitch para apresentar um branch. E então você vai dizer git rebase. E então o HashCode do commit para o qual você gostaria de rebase. Nesse caso, será o segundo commit do branch master. Vou copiar os primeiros caracteres desse commit, assim. Volte para o Git Bash, cole aqui. E isso agora deve rebasear o recurso um branch para este comentário. Bem, esse diagrama pode não parecer tão óbvio. Mas se você notar, temos o recurso um branch, que é baseado no segundo commit off master branch. Esses dois commits que pertenciam ao branch master não fazem parte do branch do recurso um. Como esperado, o gráfico pareceria mais óbvio se fizéssemos outro comentário no branch master. Então, vamos fazer isso bem rápido. Vou voltar para o branch master. Vou apenas adicionar uma linha de código, arquivo do produto, salvei o arquivo. Vamos voltar aqui e confirmar essas alterações no branch master com a mensagem. Agora, se você voltar ao gráfico, temos o branch master em azul e o branch feature em vermelho. Mas se você notar ramificações de recursos agora com base no segundo comentário no branch master, porque nós o rebaseamos para isso. E nem sempre precisamos fazer rebase para o branch master. Também podemos fazer o melhor de um ramo específico para outro ramo que não seja um branch master. Deixe-me mostrar o que quero dizer. Em primeiro lugar, vamos criar uma nova ramificação. Mas desta vez, em vez de criar um branch na ponta do branch master, eu vou fazer isso nesse commit específico. E sim, também podemos criar novas ramificações baseadas em um commit específico. Eu posso simplesmente clicar com o botão direito do mouse no commit de onde eu gostaria de criar a ramificação. Em seguida, clique em Create Branch, insira o nome do branch e estamos bem. Mas vamos ver como podemos fazer o mesmo no Git Bash. Deixe-me mudar para master, por exemplo, git branch e, em seguida, o nome do branch que gostaria de criar. Vamos chamá-lo de recurso dois. E então você vai especificar isso com base no que você gostaria de criar esse branch. Vou copiar os primeiros caracteres desse objeto commit. Volte para o Git Bash, cole aqui. Na verdade, se você executar esse comando, não precisará mudar para as marcas principais. Você pode executá-lo a partir de qualquer outro branch. Então, agora temos um ramo criado que é baseado nesse combate específico. E você pode ver esse ramo aqui. Vamos fazer um commit nesse branch. Para isso, deixe-me mudar para o recurso dois ramos. Vá para talvez um arquivo de produto. produto muda de recurso para qualquer coisa. Salve o arquivo. E vamos confirmar essas mudanças no recurso para o branch. Se você notar, a primeira linha está representando o recurso a ser ramificado e é baseada no terceiro commit do branch master. Então isso é FY21 ser hash, que inserimos anteriormente. E então essa linha vermelha representa o ramo mestre, verde representa o recurso um ramo. Se você quiser que esse gráfico pareça mais óbvio, vamos fazer um commit no branch master. Mais uma vez. Vamos confirmar essas mudanças com a mensagem. Se você voltar ao gráfico, você verá que temos o branch master, branch feature do feature um branch que é baseado fora do segundo commit e feature two branch que é baseado no terceiro comentário. Agora vamos em frente e ler o melhor recurso uma ramificação até a ponta do recurso para ramificar. Vamos primeiro mudar para o recurso de um ramo. E então eu vou clicar com o botão direito do mouse nesse commit. Rebase o ramo atual neste comitê. Temos conflitos. Vamos resolvê-los rapidamente. Aceitar as duas alterações salvas no arquivo, permanece o arquivo. E depois comprometido. Isso deve abrir um editor. Basta fechá-lo. E isso terminaria a operação de rebase. Mais uma vez, o gráfico pode não parecer tão obviamente faz mais um comentário. Na filial principal. Vou voltar para o branch master, ir para o produto ponto TXT e apenas adicionar mais uma linha de código. Vou usar o mesmo texto da mensagem do commit. E vamos nos comprometer neste momento, se você notar, a primeira linha está representando o branch master. Mas o ponto aqui é que conseguimos refazer o rebase do recurso um ramo na ponta do recurso para ramificar. Portanto, esses dois commits pertenciam ao arremessador de um ramo que será rebaseado para apresentar dois ramos. Agora, se desejar, você pode simplesmente ir em frente e mesclar essas duas ramificações e excluir uma delas ou fazer o que for. Se você quiser fazer o mesmo a partir do Git Bash basta voltar para feature one branch, git rebase, feature two. E isso deve rebasear seu recurso no branch na ponta do recurso para ramificar. Como já fizemos isso, não preciso executar esse comando. Mas espero que você tenha entendido. Então vá em frente e experimente isso, brinque com tudo o que acabei de discutir. Se você não praticar, tudo pareceria países e, se seguisse, você começaria a ficar frustrado. Vejo você a seguir. 50. 0506 Quando usar rebase e quando usar usecases: Então rebase ou mescle. Vamos falar sobre isso. Imagine que esse é o estado atual do seu projeto. Você criou uma ramificação de recurso ou o primeiro commit no branch master. E então você tem um monte de commits feitos no branch master após a criação do branch feature. Agora, digamos que, por algum motivo, você percebe que é muito cedo para criar esse ramo. Talvez você precisasse de algumas das alterações introduzidas na ramificação master que vieram depois que você criou a ramificação de recurso. Adivinha? Você pode simplesmente refazer o rebase do branch de recurso para um commit específico que veio depois, para que você tenha todas essas alterações no branch master, que estariam disponíveis no branch de recurso. Esse é um caso de uso em que você pode querer usar o rebase em uma mesclagem. Outro caso de uso fora do rebase. Digamos que você tenha criado alguns ramos como está vendo aqui. Agora, digamos que você tenha percebido que esses dois ramos não deveriam estar em dois ramos diferentes. Eles podem estar abordando o mesmo problema ou podem pertencer ao mesmo recurso. Então, talvez você queira tê-los como parte de um único ramo. Adivinha? Você pode simplesmente fazer o rebase de uma das ramificações com a outra, assim, e você está pronto para ir. No entanto, existem certos cenários em que o rebus não é a melhor opção. Rebase você está alterando e reescrevendo a boa história. Toda vez que você rebase, você está reescrevendo os objetos Comment apontando para um pai diferente. Esse não é o caso com muita coisa. Você vai manter o histórico de commits e sair da mesclagem. E esse é um motivo pelo qual você deve evitar o uso de rebase. Se houver vários desenvolvedores trabalhando em uma única ramificação. Por exemplo, imagine que temos B2 cada vez mais maçante e, em seguida, também temos o repositório centralizado. E essa é a estrutura atual do projeto. Em todos esses lugares, temos o branch master com alguns comentários e branch feature com um único commit. Agora, digamos que o dólar por um tenha sido rebaseado em um commit diferente. Isso não será refletido em todos os outros sistemas. Por exemplo, todos os outros desenvolvedores e até mesmo no repositório centralizado. Agora, para encurtar a história, isso vai criar muitas inconsistências e pode destruir o próprio propósito do motivo pelo qual temos rebase, que é ter um histórico de commits limpo. Como regra geral, lembre-se, se você é o único que está trabalhando em uma ramificação específica, uma ramificação de recurso, digamos que possamos usar o rebase antes de realmente enviar esse código no repositório centralizado. Se houver vários desenvolvedores envolvidos e todos estiverem contribuindo para o mesmo ramo. Em seguida, mescla opção para você Nesse caso. Vejo você em seguida. 51. 0601 O que está fazendo com que é usar Exemplo de ação: Vamos falar sobre esconder. Vamos, no momento, estou trabalhando em mudanças relacionadas ao recurso um. E, portanto, estou atualmente no ramo de destaque um. Agora, enquanto eu ainda estou trabalhando nisso, meu chefe vem até minha mesa e me pediu para continuar trabalhando no recurso dois e entregá-lo primeiro antes de trabalhar no recurso um, talvez esse cliente esteja ansioso esperando pelo recurso também. Agora, na esperança de uma avaliação, posso dizer sim ao meu chefe e não gostaria de começar a trabalhar no recurso também. Mas e se eu tiver algumas mudanças não confirmadas no recurso um? Deixe-me ir em frente e fazer algumas alterações em um desses arquivos. Como se eu estivesse introduzindo algumas mudanças relacionadas ao recurso um. Vou simplesmente adicionar uma linha de texto, assim, salvar o arquivo e fechá-lo. Deixe-me voltar para o Git Bash. Então, temos algumas mudanças introduzidas para o recurso um. E agora queria trabalhar no recurso para me permitir mudar de recurso para ramificação. Atualmente, estou no recurso para ramificar. Agora, se eu abrir esse arquivo admin dot TXT, você estaria vendo as mudanças que acabei de introduzir? Vamos dar uma olhada. Você ainda vê essas mudanças. Isso ocorre porque o Between branches carrega todas essas mudanças não confirmadas com você. Essas são as mudanças relacionadas ao recurso um. E eu consigo ver isso mesmo depois de mudar para o recurso dois. Agora, por que isso é um problema? Bem, quando você está trabalhando no recurso para mudanças relacionadas, isso pode realmente criar muita confusão, especialmente quando você está tentando preparar todos os arquivos relacionados ao recurso dois. Você pode se deparar com mudanças relacionadas ao recurso um e pode acabar se confundindo. Então, qual é a solução aqui? Obviamente, uma solução é confirmar as alterações relacionadas ao recurso um antes de mudar para a ramificação do recurso dois. Mas isso não é uma solução, porque também não terminamos com as mudanças no recurso um. Bem, que tal termos o recurso que nos permite armazenar todas as nossas alterações não confirmadas temporariamente em algum lugar do repositório. E então poderemos recuperá-los sempre que quisermos. Isso é exatamente o que está escondido no Git. Atualmente, estou em uma filial futura. Então, antes de mudar para o recurso dois e começar a trabalhar nele, eu gostaria de esconder todas as nossas mudanças não confirmadas. O comando para isso é bom. Esconder. Agora, esse comando armazenará apenas os arquivos rastreados por padrão. Para criar um arquivo rastreado pelo Git. Como você já deve saber, precisamos prepará-lo pelo menos uma vez. Então, se tivermos um novo arquivo que nunca foi preparado antes, não podemos escondê-lo. Se você quiser esconder todos esses arquivos não rastreados também, então o Inuit inclui uma opção. Incluir hífen não rastreado. Preciso executar este comando com esta opção que as alterações tanto encenadas quanto eu, mesmo os novos arquivos que nunca são tratados antes, sejam armazenados. Como alternativa, a abreviação dessa opção é simplesmente usar hífen novo. Atualmente, não temos nenhum arquivo que não seja rastreado de qualquer maneira. Então, vemos uma mensagem que diz Diretório de trabalho salvo e data de índice. Wip representa o progresso do trabalho no ramo do recurso um. E está apontando para o commit mais recente do branch do recurso um, o que significa que esse comando escondeu as alterações que vieram após o commit mais recente, esse branch. Agora, se você abrir o arquivo TXT do ponto admin, não verá mais todas essas alterações porque elas foram escondidas. Agora estamos livres para mudar para o recurso de duas ramificações. E aqui eu trabalho no recurso para mudanças relacionadas ou faço um monte de commits. E quando eu terminar com isso, eu posso voltar novamente para o recurso um. E eu posso recuperar todas essas alterações escondidas com o comando git stash, pop. Vamos executar esse comando. O bom comando pop. Depois de recuperar todas as alterações não confirmadas novamente, ele excluirá essas alterações do armazenamento temporário. Mas nos bastidores, essencialmente, ele criou um objeto commit, e este é o HashCode dele. E esse objeto commit não fará parte de nenhuma ramificação. Histórico, é apenas um objeto de commit temporário criado junto com ele instantâneo apenas com o propósito de stashing. E como você pode ver por essa linha, esse objeto commit foi descartado. Se você abrir o admin dot TXT agora, poderá ver novamente todas as alterações que estavam escondidas anteriormente. Existem outros casos de uso em que ele fica escondido pode ser útil. Nós os exportaremos em nossas próximas palestras. Vejo você em seguida. 52. 0602 Aplicando o traço em vários ramos: Pode chegar um momento ou um caso de uso em que talvez você precise aplicar as mesmas alterações em várias ramificações. Nesse caso, o git stash pop não serve ao propósito. Quando usar o git stash, solicite o mesmo. Deixe-me mostrar o que quero dizer. Atualmente, estou em uma filial futura e temos algumas mudanças não confirmadas. Deixe-me voltar ao Git Bash e esconder todas essas mudanças não confirmadas. Então, fizemos um backup dele e não veríamos mais essas mudanças. Agora vamos fazer git, stash, apply. E vamos ver o que isso vai fazer. Mais uma vez, o bem trouxe de volta todas aquelas mudanças não confirmadas da loja temporária. Mas desta vez ele não excluiu todas essas alterações do armazenamento temporário, como fez no gás do git stash pop. O que significa que também podemos aplicar essas alterações em outro ramo. Mas antes disso, deixe-me comprometer todas essas mudanças. Digamos que eu terminei com todas as mudanças relacionadas ao recurso um. Prepare esses arquivos primeiro e, em seguida, confirme as alterações. Deixe-me agora mudar para o recurso git stash de dois ramos. Agora posso executar o comando apply para aplicar todas essas alterações escondidas. Mais uma vez, atualmente não temos todas essas mudanças no futuro para ramificar. Mas uma vez depois de executar esse comando, você verá essas mudanças aqui. 53. 0603 Recuperando um traço específico que traça conflitos: Vamos ver como podemos dar uma olhada na lista stashes e conseguir recuperar um stash específico? Sim, é possível. Deixe-me mostrar o que quero dizer. Para explicar isso melhor, mais uma vez trouxe de volta o projeto para o que era no início deste capítulo. Então, basicamente, não temos nenhum esconderijo. Estou em destaque um ramo. Deixe-me ir em frente e editar um dos arquivos. Deixe-me simplesmente adicionar uma linha de texto, assim, salvar o arquivo, fechá-lo, voltar ao Git Bash e vamos esconder essas alterações. Volte e abra o arquivo. Não veria mais todas essas mudanças porque elas estavam escondidas. Deixe-me adicionar mais uma linha de texto, assim, salvei o arquivo, feche-o. Deixe-me esconder essas mudanças também. Agora, fizemos o stashing algumas vezes, e isso deve ter sido mantido em algum lugar no repositório. Como vamos dar uma olhada nisso? O comando para isso é git stash list. Isso seria listado em toda a lista de stashes. Podemos recuperar um estoque específico usando seu ID. Mas se você notar, a mensagem aqui não é muito descritiva. Este é apenas o último commit no recurso um branch e o mesmo usado para todos os stashes. Agora, com o tempo, conforme seus estoques aumentam, pode ser difícil identificar se stash tem quais mudanças? Felizmente, o git nos permite dar uma mensagem descritiva enquanto estamos escondendo. Então, deixe-me editar outro arquivo. Talvez inventado ou TXT assim. E eu vou fazer o mesmo para o arquivo do produto também. Salve e feche. Acabei de fazer edições e alguns arquivos. Deixe-me esconder essas mudanças, mas desta vez vou dar uma mensagem descritiva. Salvar é a opção que precisamos usar e você fornecerá alguma mensagem, algo assim. Nossas mudanças estão escondidas. Para dar uma olhada na lista de stashes. Agora, você verá uma mensagem descritiva. Agora deixe-me tentar recuperar esse estoque em particular. Mais uma vez, podemos pop as alterações são aplicadas, as mudanças. Deixe-me aplicar as mudanças. Eu queria especificar a ideia do esconderijo como célula. Você pode ver que as alterações foram recuperadas e aplicadas. Da mesma forma, também podemos recuperar esse estoque específico. E vamos ver essas mudanças no arquivo TXT ponto admin. Mas vamos ver o que aconteceria se eu recuperasse esse estoque em particular, onde editamos exatamente o mesmo arquivo. Essa operação, eu realmente deveria falhar. E com certeza, temos uma seta que diz que suas alterações locais nos seguintes arquivos seriam substituídas por mesclagem. Por favor, confirme que suas alterações estão escondidas antes de mesclar. Então, basicamente, esse Stash vai reagir às mudanças que podem entrar em conflito com nossas mudanças não confirmadas existentes. Então, para que serve a solução? A solução já está fornecida aqui. Podemos confirmar todas essas alterações ou escondê-las mais uma vez e, em seguida, recuperar esse estoque específico. Ou, como alternativa, podemos simplesmente usar o comando git restore dot para eliminar todas as alterações não confirmadas. E dessa forma , poderemos recuperar um estoque específico sem nenhum problema. Mas também perdemos todas as mudanças. Na verdade, vamos falar sobre como podemos lidar com conflitos enquanto escondemos. Quando falamos sobre git pull nos capítulos posteriores. Vejo você em seguida. 54. 0604 Stashing Seletivas Mudanças e recuperando-as Entendendo o Hunk: Não é necessário que tenhamos que esconder todas as mudanças. Também podemos escolher pedir para regar todas as mudanças que queremos esconder e mudanças que não queremos esconder. E mais uma vez, por causa deste exemplo, eu trouxe de volta o projeto para o que era no início deste capítulo. Portanto, não temos nenhum estoque no momento. Deixe-me editar alguns arquivos. Assim. Eu salvei o arquivo. Mas desta vez, vamos esconder mudanças parciais. Desta vez, vou usar a opção hífen P significa parcial. E vamos ver o que isso nos permite fazer. Ele nos forneceu várias opções. Se você não sabe do que se trata essas opções, basta digitar o ponto de interrogação e poderá ver uma descrição dele. Então, basicamente, esse comando solicitaria todas as mudanças que fizemos uma por uma. E podemos dizer o que fazer com essas mudanças base nessa lista de opções. Então, atualmente, ele está apontando para essa mudança específica pertencente ao arquivo TXT de ponto de inventário. Se digitarmos y, ele vai esconder o pedaço. Você pode pensar no pedaço como uma mudança que está sendo apresentada aqui. Portanto, esta é uma nova linha de textos que acabaria de ser adicionada. Se você digitar N, isso significa que você não quer incluí-lo como parte do stash. Isso significa que você não quer esconder essas mudanças. Q como em gracejado, não esconda esse pedaço ou nenhum dos restantes. Mas quais são todos os pedaços que você poderia ter dito sim para o que ainda está escondido ao desistir. Essencialmente, vamos sair dessa operação ao mesmo tempo, esconder todas as alterações às quais dissemos sim aqui significaria esconder esse pedaço e todos os fragmentos posteriores no arquivo. No mesmo arquivo. D significaria que eles não estão escondidos neste pedaço ou qualquer um dos pedaços posteriores no arquivo, é o oposto da opção a. Ele significaria editar manualmente o pedaço atual. Isso é algo que nunca usaríamos. Eu pessoalmente nunca usei isso. Não penso em um caso de uso para usar isso. Basicamente, se quisermos editar alguma coisa, preferimos fazer isso descendo uma árvore e depois escondendo as mudanças. Então, digamos que eu gostaria de esconder essas mudanças. Então, eu vou ficar aqui. Em seguida, ele nos solicitará o segundo pedaço, que pertence ao arquivo TXT do ponto do produto. E essas são as mudanças. Digamos que eu não queira esconder alguém para dizer não a isso. Vamos fazer git restore dot para limpar nosso diretório de trabalho. Vamos chamá-lo com esse comando. Estamos excluindo todas essas alterações não confirmadas. Deixe-me tentar reaplicar esse estoque. Esse comando aplicaria apenas o estoque mais recente que temos na lista. Mas antes de executar esse comando, vamos nos certificar de que nossas mudanças sejam perdidas. Como você pode ver, nossas mudanças não estão lá. Mas uma vez depois de executar esse comando, veremos as alterações aplicadas no arquivo TXT de ponto de inventário. Porque esse pedaço estava escondido. Onde está no arquivo TXT de ponto do produto, não vemos nenhuma alteração. Vejo você em seguida. 55. 0605 Explorando armadilhas no código VS: Agora vamos dar uma olhada em como podemos realizar o stashing do Visual Studio Code. E mais uma vez, com esse propósito, trouxe o projeto de volta ao que era no início deste capítulo. E atualmente não temos nenhum esconderijo. Vamos em frente e fazer edições em alguns desses arquivos. Pode adicionar uma linha de texto como um arquivo TXT de ponto administrativo. E deixe-me fazer o mesmo no arquivo TXT de ponto de inventário , salvei o arquivo. Vamos para o controle de origem. Clique nesses três pontos e você verá a opção de realizar stash. Então, aqui você encontra uma rotina que aprendemos até agora neste capítulo. Nós podemos executar Stash. Stash, que também inclui arquivos não rastreados. Podemos aplicar o último estoque. Isso é tão bom quanto estamos executando o comando git stash apply. Ou podemos escolher essa opção que diz aplicar estoque. E então podemos escolher um dos esconderijos salvos. Vamos em frente e realizar o stashing. Ele está nos pedindo para inserir uma mensagem, deixar o Centro ou algo assim, pressionar Enter. Portanto, isso deve ter salvado como as mudanças. 1 segundo, vamos para o Stash. Podemos clicar em Aplicar letras stash, ou podemos escolher esta opção que diz um plus stash. E então podemos escolher o estoque que gostaríamos de aplicar. Atualmente, temos apenas um estoque e dizemos que ele está sendo exibido. Se tivéssemos uma lista de stashes, eles também seriam exibidos. Deixe-me clicar nisso. E como você pode ver, as alterações por enquanto aplicadas em ambos os arquivos. Vamos ver quais outras opções temos. Também temos a opção de estourar o estoque mais recente, estourar um estoque específico. Ou podemos até largar esse traço ou largar todos os estoques. Essencialmente, soltar significaria excluir um estoque. Isso é semelhante a executar o comando git stash drop. E então você vai especificar esse ID de traço. Ou você pode simplesmente dizer git stash, claro. E isso excluiria todos os estoques. Podemos fazer isso daqui ou também podemos executar o comando. Deixe-me executar o comando. Agora. Se eu fizer git stash list, você não verá nada porque acabamos de excluir tudo. Mas é assim que você usa stashing no Visual Studio Code. Vejo você em seguida. 56. 0701 Git Ignore e é importância (curso de traços): Vamos falar sobre gitignore e seu significado. Pode haver um certo conjunto de arquivos que você não deseja confirmar ou que não deseja que eles estejam disponíveis para download e uso de outros. Alguns dos exemplos desses arquivos são os seguintes. Podemos ter arquivos de log que são gerados durante o tempo de execução. E, obviamente, não queremos comprometê-los e disponibilizá-los em um repositório centralizado para que outros possam fazer o download. Da mesma forma, podemos ter compilado código como arquivos de classe ponto ou ponto p-y, arquivos C, etc. Ou você pode ter pastas de dependência locais como módulos Node no caso de projetos fora do nó. Mas podemos ignorar esses arquivos simplesmente não os encenando e não os comprometendo. Mas pode haver casos em que as pessoas tendem a cometer acidentalmente alguns desses arquivos, criando assim uma bagunça que não é intencional. Portanto, o arquivo gitignore é útil lá. arquivo Gitignore permitirá que você especifique certos padrões. E todos os arquivos e pastas que correspondam esses padrões seriam ignorados para preparação ou acomodação. Se você tentar permanecer como os arquivos que correspondem a esses padrões especificados no arquivo dot ignore, você verá um erro. Vamos dar uma olhada em alguns exemplos desses padrões. Quando você diz log de ponto estrela, por exemplo, estrela é considerada um caractere curinga. Isso significa que você pode ter qualquer arquivo em seu repositório ou projeto com qualquer nome. Contanto que tenha extensão de log de pontos, esses arquivos serão ignorados. Então, aqui estão alguns dos exemplos de arquivos que seriam ignorados quando você tiver esse padrão especificado no arquivo doubt ignore. Adicionamos dot log no diretório raiz e seguida, info dot log na pasta logs. Ambos os arquivos seriam ignorados. Vamos dar uma olhada em mais um exemplo de um padrão. Temos um corte de pulmões. Quando você especifica uma barra, isso significa um diretório. Esse padrão basicamente ignoraria todo o conteúdo, incluindo subdiretórios de todas as pastas com o nome logs. E aqui estão alguns exemplos de arquivos que seriam ignorados com esse padrão. Pause o vídeo, tire um segundo e tente entender isso. Todos esses arquivos pertencem ao diretório Logs. E assim, todos esses arquivos seriam ignorados. Não podemos encená-los e, portanto, não podemos nem chegar até eles. Digamos que você tenha essa estrutura de projeto. Normalmente, tendemos a ter um arquivo de ignorar ponto e isso entraria no diretório raiz do projeto. No entanto, isso não impede que você tenha arquivos dot ignore nos subdiretórios também. O arquivo dot ignore e seus padrões são aplicados na pasta em que ele reside, incluindo suas subpastas. Portanto, todos os padrões no arquivo dot ignore que reside em uma pasta secundária são aplicáveis apenas em uma pasta secundária. E todos os seus subdiretórios, incluindo todos os arquivos. Mas não é aplicável em sua pasta pai, que neste caso é a pasta do meu aplicativo. Pode haver casos em que você possa ter conflitos de padrões. Por exemplo, podemos ter um padrão que pode estar em conflito nesses arquivos de dois pontos ignorados. Nesse caso, os padrões de subuma pasta terão maior precedência sobre os padrões na pasta do meu aplicativo. Vamos dar uma olhada em um exemplo disso a seguir. E assim você terá melhor clareza. Se você tiver algum padrão que não seja aplicável a toda a equipe, mas que seja aplicável apenas em sua inscrição local. Você pode mencionar a parte em massa do arquivo de exclusão. E o fato de esse arquivo pertencer à pasta dot git significa que isso não pode ser piorado ou você não pode confirmar essas alterações. E para todos os padrões que são aplicáveis a toda a equipe, esse é um arquivo dot ignore entraria em cena e é versionado, o que significa que uma vez que você faça uma atualização no arquivo dot ignore, você os comprometeria e, na verdade, enviaria todas essas alterações para o repositório centralizado para que todos os outros baixassem o arquivo de ignorar do Dart. E todos os padrões de arquivo nesse arquivo seriam ignorados para todos. Assim, ninguém seria capaz de confirmar todos os arquivos que não devem ser compartilhados com a equipe. Você também pode especificar padrões globais que são aplicáveis em todos os projetos repositórios em sua inscrição local. Você pode fazer isso executando esse comando que você está vendo aqui. Isso basicamente adicionaria uma configuração adicional no arquivo de configuração do Git que reside no diretório do usuário. Vejo você em seguida. 57. 0702 Git Ignore em ação: Digamos que git ignore uma ação. O que temos aqui é o nosso bom velho aplicativo my app com vários arquivos e talvez com vários commits também. Esqueça todos os commits que fizemos e simplesmente não se importe com os arquivos nele. Vamos nos concentrar no gitignore. Agora imagine que eu baixei esse projeto do repositório centralizado e até mesmo iniciei o aplicativo. Quando faço isso, posso acabar vendo isso em arquivos de log sendo gerados automaticamente pelo aplicativo. Agora, como não o temos executando o aplicativo, vamos simular o comportamento criando manualmente os arquivos de log. Deixe-me criar talvez qualquer um dos arquivos de log de pontos. Aqui, ele considerou que esse arquivo é realmente como criá-lo pelo aplicativo. Também pode criar uma pasta com as informações de nome onde podemos ter para registros. Então, deixe-me criar um arquivo com o nome para log de pontos. Assim. Agora, se eu iniciar o Git Bash, eu posso realmente preparar esses arquivos. Git add dot log. Como você pode ver, eu sou capaz de preparar este arquivo, o que não é algo que eu queira fazer. Então, deixe-me rapidamente no palco deste arquivo. Agora, como eu me evito de preparar acidentalmente esses arquivos de log? Bem, uma solução é entrar nas informações da pasta dot git. E então temos esse arquivo de exclusão onde você pode especificar os padrões que deseja que ele ignore. Assim, poderíamos especificar um log de ponto estrela padrão e, dessa forma, não podemos prepará-los ou confirmá-los. Mas desta vez não queremos usar esse arquivo. Você consegue adivinhar por quê? Porque esses arquivos de log não são algo local para minha inscrição. É aplicável a todos os membros da equipe. Qualquer pessoa da minha equipe que baixar esses projetos e executar o aplicativo, poderá ver esses arquivos de log. Também não quero que eles consigam confirmar esses arquivos e o repositório centralizado. Bem, é aí que gitignore entra em cena. Então, deixe-me criar arquivo dot gitignore, ponto git. Ignorar. Certifique-se de obter o nome correto. Vamos abrir esse arquivo e adicionar esse log de ponto estrela padrão. Portanto, isso deve ignorar todos os arquivos de log em nosso projeto. Agora, se eu voltar ao Git Bash e tentar preparar esse arquivo, ele realmente verá um erro que diz que as partes a seguir são ignoradas por um de seus arquivos dot ignore. Se eu ainda quiser adicionar esse arquivo de qualquer maneira, posso usar essa opção hífen F para este arquivo em quatro estágios, que deveria ser ignorado. Mas você não quer fazer isso menos que saiba o que está fazendo. Não podemos nem mesmo preparar para o log de pontos que está dentro da pasta info. Recebemos o mesmo erro. E se você tiver algum arquivo que deseja ignorar e deseja todos esses padrões sejam aplicáveis em todos os repositórios em sua máquina local. Em seguida, você deseja especificar o arquivo de exclusão global com o comando git config global. E então você vai dizer arquivo de exclusão principal. E aqui você forneceria o caminho, o arquivo dot ignore. Depois de executar esse comando, o arquivo de configuração global do Git será atualizado. Isso está dentro do diretório do seu usuário. Na verdade, vou te levar lá. Portanto, atualmente só tenho as credenciais globais que eu quero usar para todos os repositórios em minha inscrição local. Mas uma vez depois de executar esse comando, você verá essa propriedade específica sendo preenchida neste arquivo. quer que eles ignorem o arquivo para o qual ele está apontando, seus padrões seriam aplicáveis a todos os repositórios em sua máquina local. De um modo geral, você deseja especificar os padrões que são relevantes para os arquivos do sistema operacional, como ponto, DS, loja, etc., e não arquivos relacionados ao projeto. Já que não temos nada, eu só quero não executá-lo. Depois de criar ou atualizar o arquivo dot Git ignore, você deseja confirmar essas alterações e até mesmo enviar suas alterações para o repositório centralizado para que todos esses padrões sejam aplicáveis para todas as pessoas da sua equipe. Falaremos sobre como você pode enviar seus commits locais para o repositório remoto em capítulos posteriores. Mas, por enquanto, posso ir em frente e entrar no arquivo gitignore. Git add, git, ignore status, git commit, hífen , seja o que for. E somos capazes de cometer essa mudança. Vejo você em seguida. 58. 0703 Ordem de precedência substituindo erros de teste padrão: Vamos falar sobre precedentes. Digamos que temos mais um arquivo dot gitignore em um dos subdiretórios. Deixe-me copiar esse arquivo para o diretório de informações assim. Mas em vez desse padrão, eu quero ter esse padrão. Ou esse padrão significa que queremos ignorar todos os arquivos que não têm extensão de log de pontos. Agora, se você perceber que temos um conflito de padrões. No diretório raiz. Temos um padrão que diz que queremos ignorar todos os arquivos de log de pontos. Mas enquanto aqui com esse padrão, estamos dizendo que queremos ignorar todos os arquivos. Isso não é um arquivo de log de pontos. Qual padrão deve ser seguido. É aí que os precedentes entrarão em cena. Nesse caso, esse padrão seria preferido em relação ao do diretório pai. A maneira como funciona é quando você tem um arquivo como info dot log in, ele verificará se há algum arquivo dot gitignore no mesmo diretório em que esse arquivo está residindo. Se houver, ele tentará encontrar padrões, uma correspondência com esse arquivo. Se não houver padrões que correspondam a esse arquivo, ele procurará padrões no diretório pai. Se ele ainda não encontrar lá, ele tentará encontrar os padrões dentro do arquivo de exclusão. Se ele não encontrar padrões ali também que correspondam ao arquivo específico. Em seguida, ele entrará e verificará o arquivo global de ignorar. Se tivéssemos configurado isso. Se não encontrar em nenhum lugar, isso nos permitirá preparar esse arquivo. É assim que o precedente andaria. Agora, se eu for ao Git Bash, vamos ver se podemos preparar o log de pontos de informação. Podemos, como você pode ver, podemos realmente preparar log de pontos de informações porque o padrão nessa pasta, as vendas que queremos incluir neste arquivo e não queremos ignorá-lo. Na maioria dos casos, porém, normalmente em quase todos os projetos, você teria apenas um arquivo gitignore de ponto e isso vai dentro do diretório raiz. Mas estou compartilhando isso apenas para sua informação. Também devo mencionar que não estamos restritos a alguns padrões. Temos vários padrões que podemos usar dependendo de quais são todos os arquivos que você deseja ignorar. Na maioria dos casos, normalmente seria isso. Ou você pode acabar especificando uma pasta como essa. Todos os padrões que você pode consultar na documentação oficial. Não há muitos. Pode apenas dar uma olhada rápida e ter uma sensação de peso como padrões que são suportados. Não faz sentido para mim orientá-lo em cada padrão e ocupar todo o seu tempo. Basta consultar a documentação e ela tem tudo o que você precisa. Às vezes, você pode ter tantos arquivos ignorados. Isso torna difícil entender por que um determinado arquivo está sendo ignorado. Nesse caso, temos um comando à mão. Você disse Get, check. Ignorar com hífen v opção significa detalhado. E então você especificará o nome do arquivo. Por exemplo, Error dot loc. E isso vai mostrar por que esse arquivo está sendo ignorado. Como você pode ver, temos arquivo dot ignore no diretório raiz. E esse padrão está combinando com esse arquivo. E é por isso que está sendo ignorado. Isso pode ser útil, especialmente se você tiver vários arquivos ignorados ou não tiver certeza do motivo pelo qual um determinado arquivo está sendo ignorado. 59. 0704 Ignore arquivos que já estavam comprometidos: E se já tivéssemos cometido as mudanças deveriam ser ignoradas? Deixe-me mostrar o que quero dizer. Para esse fim. Mais uma vez, eu trouxe de volta o projeto para o que era no início deste capítulo. Mais uma vez, temos esses três arquivos e começaremos a partir daí. Deixe-me ir em frente e criar um arquivo de log. Vamos chamá-lo de log de pontos de erro. Deixe-me ir em frente e confirmar esse arquivo de log. Como se eu estivesse confirmando esse arquivo acidentalmente, junto com várias outras mudanças. Git add error dot log, git, commit Typhon, alguma mensagem, e nós confirmamos o arquivo de log. Agora imagine que nosso projeto é muito novo, nossa equipe é muito nova. Ninguém está familiarizado com o arquivo dot ignore. E então vamos dizer que temos um monte de arquivos no repositório, estão no repositório centralizado comprometido por um monte de pessoas que deveriam ser ignorados. Agora, neste momento, percebi que precisava ter o arquivo dot gitignore no meu diretório raiz. Então, vou incluí-lo dot Git, ignore. Vou especificar vários padrões, que eu queria ignorar. No meu caso, vou simplesmente dizer “star dot along”. Assim. Deixe-me renomear esse arquivo corretamente. Era para ser bom. Ignore assim. Agora já é tarde demais porque já fizemos commit de todos os arquivos que não deveriam estar nele. Deixe-me ver esse arquivo também. Git add, git, commit Typhon estou introduzindo o arquivo ignore. Agora eu apresentei esse arquivo, o que é ótimo. E isso agora ignorará todos os arquivos que deveriam ser ignorados. Mas e quanto a todos os arquivos que já foram confirmados? Como nos livramos deles? Bem, uma solução simples é simplesmente identificar todos esses arquivos, excluí-los e, em seguida, fazer um commit. Todos esses arquivos serão excluídos. E a partir de agora temos o arquivo dot gitignore, qualquer forma para evitar que isso aconteça. Mas, na prática, se você tem muitos arquivos, torna-se realmente impraticável identificar todos os arquivos que você queria eliminar. Temos uma solução melhor? A resposta é sim. Temos um trabalho sorrateiro para resolver esse problema de forma mais eficaz. Deixe-me mostrar o que quero dizer. Eu vou voltar para o Git Bash. Deixe-me limpar a tela. Deixe-me fazer git status para ter certeza de que tudo está limpo. Agora deixe-me executar o comando. Git RM, hífen r significa recursivo. E então vou usar a opção em cache, seguida por um ponto final. O que estou tentando fazer aqui? Na verdade, estou tentando excluir todos os arquivos em cache. Agora, arquivos em cache de água, você pode me perguntar, bem, arquivos em cache são essencialmente os arquivos que estão sendo rastreados pelo Git. Git armazena todos os arquivos que deseja rastrear em um cache. E com esse comando, vamos limpá-los. Isso dá a impressão que realmente excluímos todos os arquivos sem precisar excluir do diretório de trabalho. Vamos executar esse comando e ver o que acontece. E como você pode ver, ele removeu todos esses arquivos do cache. Então, isso inclui literalmente todos os arquivos em nosso diretório de trabalho. Como você pode ver, temos cinco arquivos aqui. E temos cinco arquivos aqui. Em seguida, o que vamos fazer é realmente preparar todos os arquivos detectando o que vai acontecer. Mas antes disso, deixe-me executar o comando git status mais uma vez. E desta vez, se você notar seção de alterações a serem confirmadas, ele listou todos esses cinco arquivos. Isso porque nos faz pensar que realmente excluímos todos esses arquivos. Embora não os tenhamos excluído do diretório de trabalho. Acabamos de limpar o cache e acreditamos que , na verdade, excluímos esses arquivos ao mesmo tempo. Na seção de arquivos não rastreados, listou todos os arquivos que não estão sendo rastreados no momento. Agora, tome nota. Esta lista não inclui log de pontos de erro porque agora faz parte do padrão dentro do arquivo dot gitignore. O Git não quer rastreá-lo. Agora vamos em frente e adicionar todos esses arquivos não rastreados e torná-los rastreados pelo Git. Git adiciona este termo. Vou usar o caractere de ponto para que até mesmo os arquivos que começam com ponto sejam adicionados e sejam rastreados pelo Git. Agora, se eu fizer git status, você verá que o log de pontos de erro é o único arquivo que precisamos entrar. É como se tivéssemos excluído esse arquivo e feito um comentário. Essencialmente, com isso, podemos excluir todos os arquivos que não deveriam ser confirmados são os arquivos que devem ser ignorados. Agora, já que temos essa pilha preparada para ser excluída, há uma última coisa que precisamos fazer é confirmar as alterações. Limpar ignorado cinco, é como celular. E get foi excluído em um registro de pontos. Simplesmente significa que o novo instantâneo não tem mais esse arquivo. Mas é claro que ainda o temos no diretório de trabalho. Portanto, este é apenas um trabalho sorrateiro para nos livrarmos de todos os arquivos que comentamos anteriormente e que deveriam ser ignorados. Agora, se você ainda não está claro, não apresse e experimente esses comandos e você os entenderá. Vejo você em seguida. 60. 0705 Gerando os arquivos Ignore para seu projeto: Se você está introduzindo o arquivo dot gitignore em seu projeto, você realmente não precisa fazer um brainstorm sobre quais padrões você deseja manter nesse arquivo. Você pode simplesmente usar uma das ferramentas existentes com um gerador de git ignore de pesquisa rápida no Google. Me deparei com este link. Ele parou o al.com. Você pode estar vendo algum outro site, mas eles fazem o mesmo trabalho de gerar padrões para você, dependendo do tipo de projeto que você está construindo. Por exemplo, digamos que eu esteja criando um aplicativo Android. Então, basta digitar no Android e clicar em Criar. E ele me forneceu uma lista de padrões que posso adicionar como parte do arquivo dot gitignore dos meus projetos. Já estamos familiarizados com a maioria desses padrões. Todas as linhas com hash significariam comentários. Aqui estamos tentando ignorar o diretório Gradle do DOD. Aqui estamos tentando ignorar o diretório de compilação. Portanto, todo o conteúdo dele, todos os arquivos, bem como os subdiretórios, seriam ignorados para preparação. Aqui estamos tentando ignorar o arquivo de propriedades do ponto local. Star dot log significaria que queremos ignorar todos os arquivos de log. E já vimos um exemplo do mesmo. Da mesma forma, temos vários outros padrões. Vamos tentar digitar Node. E vamos ver o que isso vai gerar. Mais uma vez, temos vários padrões que você pode querer adicionar um novo nó. O projeto JS tem uma atribuição. Basta copiar um desses arquivos e tentar experimentar esses padrões e ver quais são todos os arquivos que estão sendo ignorados e fazer com que todos os arquivos não sejam ignorados. Vejo você em seguida. 61. 0801 Por que o GitHub vs Bit Bucket vs GitLab: Tudo bem, agora é hora de falar sobre o GitHub. Nós meio que já tocamos nisso no início do curso. Mas vamos tentar reiterar e tentar entender a necessidade de ter um serviço centralizado de hospedagem de código como o GitHub. Se você é o único que está trabalhando no projeto, não precisa de algo como o GitHub. Você pode simplesmente se safar com o Git que está instalado localmente para gerenciar as versões do seu projeto. No entanto, à medida que seu projeto cresce em tamanho, convém contratar mais pessoas que possam contribuir para o seu projeto. Embora seja apenas uma ou duas pessoas , você pode gerenciar facilmente sem precisar usar um serviço como o GitHub. Dezenas e centenas de funcionários que podem querer contribuir para o seu projeto, então você certamente precisa de uma maneira melhor de gerenciar seu código e seu histórico de versões. E é aí que o GitHub entraria em cena. E o GitHub age como um repositório de código centralizado onde todos contribuiriam com seu código. Essencialmente, eles fazem vários commits em seu Git local e, em seguida, carregam ou enviam todas essas alterações para o repositório centralizado. E então todo mundo poderia baixar todas as mudanças introduzidas por outros membros da equipe. Digamos que todos teriam essencialmente uma cópia de todo o projeto no computador local. , também temos uma cópia do projeto no repositório centralizado, como o GitHub, juntamente com seu histórico de versões. E isso é o que eu recebo é chamado de sistema de controle de versão distribuído. No entanto, get não se trata apenas de hospedar seu código ou manter o histórico de versões. Ele oferece muitos outros recursos que são bastante úteis para uma organização. Por exemplo, ser capaz de gerenciar os membros da equipe quanto a quem pode fazer o quê. Estão sendo capazes de revisar as mudanças introduzidas por um dos membros da equipe antes de mesclá-las ao mainstream do desenvolvimento. Você pode fazer praticamente tudo o que pode fazer em seu bom software local, como confirmar o código, criar ramificações, etc. Também lhe oferecerá comentários sobre o trabalho de alguém. Também podemos discutir coisas sobre a comunidade, etc. Agora, o GitHub não é a única opção para nós. Também temos outros players no mercado que viram exatamente o mesmo propósito. Qual deles você deseja usar depende inteiramente de seus requisitos. Se sua organização estiver usando projetos do ecossistema da Atlassian, como Jira, bamboo , etc., o Bitbucket pode fazer sentido para você porque tem uma melhor integração com essas ferramentas. E entre todos esses três, git lab é de código aberto. Os outros dois têm níveis gratuitos e pagos. E obtenha um laboratório e o Bitbucket melhor suporte para integração contínua, que é um conceito de DevOps discutido no meu curso de DevOps. Mas o GitHub é o mais antigo entre esses três. Existem milhões de projetos que dependem do GitHub e há milhões e milhões de desenvolvedores em todo o mundo que estão usando ativamente o GitHub. O Github tem uma comunidade incrível e também é a melhor escolha para projetos de código aberto. A interface do usuário também é bastante minimalista, mas tem um custo, no entanto. Ele não tem o suporte integrado para integração contínua, como com GitLab e Bitbucket. Mas tudo bem, você pode usar algumas das ferramentas de terceiros para isso. Mas não importa qual dessas ferramentas você aprenderá. Em última análise, eles têm o mesmo objetivo de gerenciar seu projeto. Eles podem diferir em termos de interface de usuário e terminologias que estão sendo usadas. Mas, caso contrário, todos eles têm o mesmo propósito. 62. Conta do Creatig GitHub: Ok, vamos ver como podemos criar uma conta no GitHub e até mesmo criar alguns repositórios. Para esse fim, eu criei uma conta falsa do Gmail, que está sob a Corp 96 em gmail.com. Como se essa empresa fosse fundada em 1996 ou o WhatsApp. Agora cilindro como freelancer, ele vai criar uma conta no GitHub para sua própria organização para que todos os outros e sua equipe possam agora começar a contribuir para o projeto no GitHub. Vamos clicar em inscrever-se. Na verdade, as instruções são bem diretas. Eu realmente não tenho que te guiar por isso, mas eu só estou fazendo isso como uma formalidade. Por isso, ele está nos pedindo para inserir o endereço de e-mail. Vou fazer exatamente essa senha. Eu já tenho isso à mão. Então, eu só vou colar. O nome de usuário será algum lá Corp 96. E levante-se diz que isso não está disponível. Então precisamos mudar isso para outra coisa, talvez 1996, agora está disponível. Vamos continuar. Ele está nos perguntando se gostaríamos de receber as atualizações e anúncios por e-mail, eu diria que não por enquanto. Se desejar, você pode optar por isso. Próximo. Ele está nos pedindo para resolver um quebra-cabeça para ter certeza de que não somos um bot. Eu só tenho que escolher essa galáxia espiral. No meu caso. Eu vou fazer exatamente isso. Fiz um excelente trabalho lá, então posso ir em frente e criar a conta. Recebemos este e-mail com o código, que eu só tenho que copiar e colar aqui. E terminamos de criar uma conta no GitHub. Praticamente. Eu só queria pular essa etapa. Se desejar, você pode escolher quantos membros da equipe você tem e se você é aluno ou professor. Mas eu vou simplesmente pular isso por enquanto. E terminamos. Agora, à primeira vista desta página de boas-vindas que você vê uma vez depois de fazer o login pela primeira vez, get up já está nos dando sugestões sobre o que podemos fazer a seguir. Podemos criar um repositório ou importar um repositório existente. Podemos introduzir um arquivo leia-me em nosso projeto. Podemos até explorar as opções para contribuir com alguns dos projetos existentes, sobre os quais falaremos posteriormente no curso. E há um monte de outras coisas que você pode simplesmente dar uma olhada e ter uma ideia do que se trata. Você não precisa ir muito fundo porque vamos explorar tudo nas próximas palestras. 63. 0803 Criação e compreensão de repositórios públicos e privados: Ok, vamos ver como podemos criar repositórios do GitHub. Podemos adicionar esse importante repositório existente. Vou criar um novo. E eu vou fazer exatamente isso. Aqui. Você vai ver o nome do dono. Nesse caso, temos apenas um proprietário. E é isso que é escolhido por padrão. Aqui você tem que fornecer o nome do repositório, o nome do repositório que você gostaria de fazer. Agora, temos que decidir se você quer tornar o projeto público ou privado. Se o seu objetivo é iniciar um projeto de código aberto, então pode fazer sentido escolher a opção pública aqui. Ou se você é uma organização em que seu software ou aplicativo é proprietário e você tem um cliente para o qual está trabalhando, então pode fazer mais sentido usar um repositório. Se for um repositório público, qualquer pessoa de todo o mundo poderá visualizar o conteúdo do seu projeto, baixar seu projeto, cloná-lo, etc. Considerando que, se o repositório for privado, você pode escolher quem pode fazer o que pode contribuir para o projeto, quem pode visualizar o projeto, etc. Vou demonstrar a criação de ambos. O repositório está assumindo que estou criando algum tipo de projeto de código aberto. Deixe-me chamar meu aplicativo como meu aplicativo público ou qualquer outra coisa. Se você quiser. Você também pode separar esses nomes com um hífen. Você não pode ter um caractere de espaço em branco. Se você incluir um caractere de espaço em branco, get assumirá automaticamente um caractere de hífen, como está sugerindo. A propósito, posso usar a palavra Git e GitHub de forma intercambiável, dependendo do contexto. Então esse é o nome do aplicativo que eu dei. Também posso escrever uma descrição rápida sobre o projeto, meu aplicativo público, o que for. E depois levante-se. Ele está nos mostrando opções para incluir alguns desses arquivos, como o arquivo Leia-me, que teria alguns detalhes sobre o projeto. O arquivo dot ignore, essencialmente quaisquer que sejam os padrões de arquivo incluídos neste arquivo, seria ignorado para ser confirmado. Em seguida, também podemos escolher o arquivo de licença. Existem certas licenças predefinidas que podemos usar se desejarmos. Por exemplo, se você estiver criando um projeto de código aberto, a gpu ou a licença pública geral podem fazer sentido para você. Por enquanto, não vou escolher nenhum desses porque podemos adicioná-los mais tarde. Mas se você escolher um desses, get criará automaticamente um commit em nosso nome, confirmando esses arquivos. A escolha é sua. Você pode escolher ou não escolher. Ambos são praticamente iguais. Vamos adicioná-los de qualquer maneira nas próximas palestras. Então, isso simplesmente criará um repositório público. Vamos clicar em Create Repository. E o GitHub está fornecendo alguns próximos passos com os quais você não precisa se preocupar, porque vamos explorá-los qualquer maneira nas próximas palestras. Mas se você voltar aqui, você pode ver que nosso repositório está listado aqui. Se você copiar o link, o link se parecerá com isso. Você tem GitHub.com e , em seguida, a barra de nome de usuário, o nome do repositório. E é assim que todos poderiam acessar seu repositório público. Agora, qualquer pessoa em todo o mundo pode acessar este link para poder ver o nosso projeto do Watson porque ele é público. Agora também vamos criar um repositório privado. Você clica no novo nome do repositório vai ser , digamos, aplicativo do banco, o que for. Meu aplicativo bancário, vou escolher a opção privada, que apenas as pessoas a quem eu der acesso possam visualizar o projeto e contribuir com ele. Na verdade, estou falando sobre colaboradores, que exploraremos em breve. Desta vez. Deixe-me escolher um desses arquivos. Talvez eu queira adicionar um arquivo de licença. Por exemplo. Isso provavelmente não pode ser uma licença pública geral. Mas você pode usar qualquer coisa. Você não precisa levar isso a sério, a menos que seja uma organização real preocupada com o licenciamento. Estou simplesmente escolhendo algo aleatório e criando um repositório. Desta vez, o github fez um commit para nós. E nesse compromisso comprometeu o arquivo de licença. Você pode clicar nesse arquivo para dar uma olhada em seu conteúdo. Você pode alterar isso se quiser e fazer outro commit. Mas vamos explorar tudo isso nas próximas palestras. Vamos voltar para a página inicial. E agora você pode ver esses dois repositórios. Agora, como este é um repositório privado, ele não pode ser acessado por mais ninguém. Infelizmente, os repositórios privados e o GitHub não têm muitos recursos que os repositórios públicos têm. Se você quiser esses recursos e repositórios privados. E mais, dica, na verdade, considere pegar alguns dos níveis pagos oferecidos pelo GitHub. A menos que você seja uma organização, não faz sentido pagar por eles. E por isso mesmo, na maioria das vezes, vamos usar o repositório público neste curso. Vejo você em seguida. 64. 0804 Fazendo comentários no GitHub e compreendendo o arquivo do ReadMe: Vamos ver como podemos fazer nosso primeiro compromisso e nos levantar. E vamos fazer isso no repositório público. O que vamos chegar é o arquivo leia-me do nosso projeto. Agora, o que é o arquivo leia-me? quer que você queira informar, os contribuidores do seu projeto entrariam no arquivo leia-me para entendê-lo melhor, vamos dar uma olhada em alguns dos projetos existentes e no GitHub e como despovoado os arquivos Leiame. Eu vou simplesmente escolher um dos projetos aleatórios. Então eu clico neste link que diz encontrar relatórios que precisam da sua ajuda. Vou simplesmente escolher um dos projetos aleatórios disponíveis aqui. Talvez esta seja a lista de tuplas a serem levantadas. Ambos são públicos. Deixe-me escolher este. Todos os projetos e o GitHub provavelmente terão o arquivo leia-me. E normalmente entra no diretório raiz do projeto. Então aqui está. Vamos ver o que está dentro dele. Basicamente, pode escrever coisas como suas informações de contato. Alguns dos links que você deseja compartilhar com as notas de dólar. Ou você pode instruí-los sobre como eles podem levantar problemas e quem entrar em contato caso haja algum problema com o aplicativo. Você também pode falar sobre o aplicativo e seus recursos, como eles estão fazendo aqui. Aqui está a lista de recursos suportados por este aplicativo. Eles estão mostrando instruções sobre como fazer o download deste projeto. E um monte de outras informações que estamos compartilhando seu roteiro para que os desenvolvedores tenham visão panorâmica de todo o projeto. Aqui eles parecem ter listado toda a lista de contribuidores, ou talvez os principais contribuidores que contribuíram para este projeto. E assim por diante. Vamos em frente e criar um arquivo leia-me em nosso repositório público. Vou escolher o repositório público que foi criado. E atualmente não temos nenhum commit. Podemos criar um novo arquivo ou fazer upload de um arquivo existente, ou podemos escolher uma dessas opções. E o gate será pré-preenchido com algum conteúdo. Já vimos que, no caso do arquivo de licença, já temos alguns modelos predefinidos. Também temos alguns modelos predefinidos pré-preenchidos para o arquivo dot ignore. Mas não vamos usar isso porque ainda não falamos sobre isso. Deixe-me escolher o arquivo Leia-me. Portanto, é o arquivo Read Me dot md. É ensinado extensão MD. Aqui. Você pode escrever o que quiser. E quando terminar, você pode rolar para baixo e clicar neste botão que diz commit new file. Aqui você pode ver que alguma mensagem padrão já foi preenchida pelo GitHub. Diz Create, Read Me dot RMD file. Se você quiser alterá-lo, você pode ir em frente e alterá-lo. Você também pode adicionar a descrição sobre esse commit. Mas estou feliz com a mensagem padrão. Então, vou simplesmente deixar como está e clicar em Commit. Nenhuma etapa de preparação é necessária. Isso faria esse trabalho internamente para nós. Depois de confirmar o arquivo, você verá esse arquivo aqui. Vamos fazer mais um commit introduzindo um outro arquivo. Deixe-me voltar e clicar nessa opção que diz Adicionar arquivo, criar novo arquivo. Talvez eu queira adicionar um arquivo TXT de quatro pontos, algum arquivo de informações de conteúdo. Deixe-me expandir isso. Vou rolar para baixo. E 1 segundo. Estou feliz com o texto pré-preenchido, mas posso alterá-lo para outra coisa, se desejar. Vou deixar essa opção como está. Já que não falamos sobre pull request. Não posso explicar agora sobre o que é essa opção. Vamos falar sobre isso nas próximas palestras. Venha com o novo arquivo. Agora temos alguns comentários. Se você clicar nesses commits, poderá ver a lista de commits que fizemos. Aqui está o HashCode de cada um desses comentários para que você possa copiá-los clicando neste ícone. Você também pode ir para um estado de um projeto em um commit específico. Ao clicar aqui. Por exemplo, se eu clicar nele, o cometa virá no arquivo Leiame. Neste momento, não temos o arquivo de informações, então não o vemos. Deixe-me voltar. Aqui. Você pode escolher o ramo. Atualmente, temos apenas uma ramificação e essa é a ramificação principal padrão. Caso contrário, você veria uma lista de ramificações e poderíamos mudar para uma das ramificações. Então é assim que você faz comentários e o GitHub. Criamos o repositório e também adicionamos alguns dos arquivos básicos, o que o torna pronto para que outros contribuam com o nosso projeto. Vejo você em seguida. 65. 0805 Criando sucursais e comprometendo mudanças: Ok, vamos ver como podemos criar um novo branch e até mesmo fazer comentários nele dentro do GitHub. Para isso, deixe-me ir a um dos repositórios. Vou usar o repositório público para isso. Aqui você pode ver uma lista de filiais. Atualmente, temos apenas um branch, o branch principal, que também é o branch padrão. Aqui você pode ver este link que diz ver todas as ramificações. Você pode clicar aqui ou também pode clicar neste link que diz uma ramificação. Diz uma filial porque atualmente temos uma filial. Vamos clicar nesse link. Aqui você vê a opção de criar uma nova ramificação. Basta clicar nesse botão, digitar o nome que você gostaria de fazer para esse branch. Algo parecido com isso. Você também pode escolher a ramificação de origem de onde deseja criar essa ramificação. Nesse caso, temos apenas uma ramificação e ela foi padronizada para a ramificação principal. Vou mantê-lo como está e clicar em Criar ramificação. Isso criou a filial para nós. Você também pode ver uma lista específica de filiais. Por exemplo, se eu clicar em ativar, isso será listado em toda a lista de ramos do Ato Dois. Ou em outras palavras, essas são as ramificações em que há pelo menos um commit feito nos últimos três meses. entanto, você não verá o branch padrão. Você pode ver a ramificação que acabou de ser criada. Esses galhos da cauda são o oposto de dois ramos. Se houver algum branch em que você não tenha feito nenhum commit nos últimos três meses, você verá uma lista deles aqui. Se você é o proprietário do repositório, talvez queira entrar em contato com colaboradores, são desenvolvedores que estão trabalhando nessas ramificações e verificar com eles se ainda querem manter essas ramificações. ou não. Você terá uma ideia melhor sobre isso à medida que progredimos neste curso. E as ramificações nesta seção seriam listadas de forma que a ramificação com o commit mais antigo fosse listada primeiro. Enquanto aqui na seção ativa, todas essas ramificações seriam listadas de forma que as ramificações com o commit recente fossem listadas primeiro. Se você clicar em todos os branches, este pé apenas mostrará o branch padrão, seguido por todos os outros branches ordenados pelos branches com o commit mais recente primeiro. Você também pode excluir uma ramificação e restaurá-la. Se você excluir uma ramificação, atualize a página e será tarde demais para restaurá-la. Assim, podemos criar uma nova ramificação. Vamos voltar ao repositório. Aqui podemos escolher o ramo para o qual queríamos mudar. Alterne para o branch de recurso. É como se tivéssemos executado esse comando which ou checkout mencionando o nome do branch. E se você notar, agora temos duas filiais aparecendo aqui. Podemos adicionar um novo arquivo nessa ramificação ou editar um dos arquivos existentes. Vamos tentar adicioná-lo. Arquivo Leia-me ponto MD. Eu clico neste ícone, o que me permitirá editar alguma mensagem. Eu quero rolar para baixo. Estou feliz com a mensagem padrão, se desejar, você pode ir em frente e alterá-la. Vou deixar essa opção como está. E clique em Commit Changes. Isso comprometeu a forma como as mudanças na nova filial. No momento, estamos na filial principal. E se você clicar no arquivo Read Me dot md e verificar seu conteúdo, notará que ele não tem as alterações introduzidas na nova ramificação do recurso. Mas se você mudar para o branch do recurso, como você pode esperar, você verá as mudanças que acabamos de introduzir e o branch do recurso. Vejo você em seguida. 66. 0901 Clonar um repo público e explorar outras opções: Anteriormente, tínhamos criado uma conta no GitHub com o nome Centre Corp 1996. E também criamos alguns repositórios. Um é público, o outro é repositório privado. Ou o repositório público deve estar disponível para qualquer pessoa no mundo ver, baixar, voar, etc. Agora vamos dizer que eu encontrei um cara com o nome Luke e eu queria que ele contribuísse para o meu repositório público. Agora imagine que estou dentro do computador do Luke. O que você precisa primeiro fazer é basicamente ter uma conta no GitHub. Então, para esse propósito, eu realmente criei uma nova conta do Gmail com o nome look Centre Corp no gmail.com vermelho e sua conta correspondente no GitHub também. Então esta é a conta de Luke e agora ele está se preparando para contribuir com o repositório público Cylinder cop 1996. Essa é a URL desse repositório. E eu consigo visualizar o projeto e seu conteúdo porque este é um repositório público. Se este for um repositório privado, não poderei visualizá-lo. Na verdade, qualquer pessoa com esse link deve ser capaz de visualizar o projeto e seu conteúdo porque é um repositório público. Agora, a primeira coisa que esse loop precisa fazer para começar a contribuir com esse projeto é ter uma cópia local desse repositório em seu computador local. O que eu estou falando é git clone. E, como o nome sugere, ele basicamente clonaria o repositório central ou o projeto em sua inscrição local. Então você clica nesse botão que diz código. E temos várias maneiras de clonar o projeto. Podemos fazer isso através, obter CLI. Get up CLI é uma ferramenta oferecida pelo GitHub. É uma ferramenta de código aberto e basicamente permitiria que você interaja com o GitHub a partir da linha de comando do seu computador. Mas essa ferramenta foi originalmente projetada para economizar algum tempo, mas essa não é uma ferramenta obrigatória como tal. A outra opção é usar SSH, que é um procedimento demorado porque, para isso, você precisa criar chaves públicas e privadas e , em seguida, armazenar a chave pública no repositório, etc. Falar sobre SSH deve ser um tópico de outro curso. Se você estiver usando SSH, então você pode usar essa opção. Se não, então temos uma opção melhor. Na verdade, essa é uma opção recomendada até mesmo pelo GitHub, que é usar o protocolo HTTPS. Esta é a melhor opção entre todas essas por duas boas razões. Número um, normalmente os firewalls não tendem a parar como tráfego HTTPS. Portanto, temos uma vantagem lá. Em segundo lugar, também ajudará o auxiliar de credenciais do seu sistema operacional a ser capaz cache ou armazenar as senhas, que não é o caso com as outras duas opções. Isso é o mais simples de tudo, e podemos seguir isso cegamente e não precisamos nos preocupar com SSH ou com a CLI. Também temos a opção de baixar o projeto. Bem, se você baixar o projeto não vai baixar os dados históricos ou o histórico de versões vai apenas baixar os arquivos no projeto. Também podemos abrir isso com o GitHub Desktop. Se você tiver o GitHub Desktop instalado, poderá abri-lo e escolher a pasta em que deseja clonar este projeto. Como não estamos usando essa ferramenta no momento, podemos ignorar isso. Então, o que vamos fazer é simplesmente copiar esse link HTTPS. Este é o link exato, como você está vendo aqui, que é o link para o repositório, Esse é github.com barra nome de usuário deste repositório, o proprietário do repositório, barra o nome do repositório em si e, em seguida, dot get extension. Isso é essencialmente o que é isso? Você está literalmente apenas copiado. Assim que tivermos esse link copiado dentro do nosso computador local, estou dentro do diretório def. Deixe-me copiá-lo novamente. Você não pode imaginar que este seja o computador do Luke. Vou usar o comando git clone. E então você vai colar esse URL. Então aqui está escrito clonagem nesta pasta. Essencialmente, ele criou uma pasta com esse nome, que é o nome exato do depositário. E o conteúdo dele constituiria exatamente o conteúdo que vimos no repositório do GitHub. E se você notar que ele realmente comprimiu todos os objetos. Basicamente, para facilitar a transferência todos os arquivos pela Internet para o seu computador local. E, finalmente, ele extraiu todos os objetos. Um total de nove objetos foram recebidos. Vamos dar uma olhada no conteúdo dentro desse diretório. Então aqui está meu limite público. Deixe-me ampliar um pouco. Como você pode ver, nós lançamos dxdy, bem como Read Me dot TXT file. Dentro da pasta dot git. Você vai ver o que normalmente vemos. Você pode ter observado algumas coisas que podem parecer estranhas para você neste momento. Vamos falar sobre eles nas próximas palestras. Por exemplo, temos os chamados controles remotos, que não estavam disponíveis quando criamos o repositório localmente. Falaremos sobre eles nas próximas palestras. É assim que você criou um depósito local, exceto que, desta vez, nós realmente clonamos um repositório existente do GitHub. Se você fosse baixar o projeto, você não veria a pasta dot git. Você só veria esses dois arquivos de projeto. Agora, esta é a razão pela qual ele é chamado de sistema de controle de versão distribuído. Você tem uma cópia de todo o repositório junto com seu histórico de versões em sua máquina local. E você também tem uma cópia dele no repositório centralizado, que é get up. E todos na organização ou na sua empresa teriam uma cópia de todo o repositório. Se um deles cair, então você tem outros sistemas de onde você pode recuperá-los. Esse é um sistema de controle de versão distribuído para você. Vamos voltar ao Git Bash. Agora, se eu executar o comando git branch, precisamos primeiro entrar nesse diretório. Meu CAP público, git branch. Você só verá o branch principal, embora tenhamos criado branch de recurso no repositório centralizado GitHub, aqui estamos vendo apenas o branch principal. Por que isso? Bem, você encontrará uma resposta para isso nas próximas palestras. 67. 0902 Clonar um repositório privado e adicionar colaboradores de projetos no GitHub: Ok, vamos ver como podemos clonar um repositório privado. Atualmente eu fiz login como remetente, quem é o proprietário desses repositórios? Um é o repositório público e o outro é o repositório privado. Já vimos como podemos clonar um repositório público. Qualquer pessoa no mundo pode realmente vê-lo, cloná-lo no sistema. Mas quando se trata de repositório privado, nem todos podem acessá-lo ou cloná-lo, a menos que o remetente os aborde como colaborador de seu projeto. Para demonstrar isso, eu realmente entrei como cilindro e também como Luke, que estaria contribuindo para o repositório privado do cilindro. Para distinguir entre essas duas contas. Aquele com o time preto pertence a sunder e aquele com o time branco pertence a Luke. Agora você precisa supor que essas duas pessoas realmente se conectaram a partir de seus próprios computadores. E, claro, não do mesmo sistema, como estamos fazendo aqui. Deixe-me copiar o link do repositório privado e tentar acessá-lo da conta de Luke. E recebemos um erro que diz 404. Esta não é a página da web que você está procurando. Isso porque a under não deu permissão para acessar esse projeto. Então, o que o remetente precisa fazer é entrar nesse repositório, ir para as configurações e, em seguida, adicionar Luke como colaborador. Deixe-me digitar a senha bem rápido. Você verá essa opção que diz Adicionar pessoas. Vou procurar por. Olha embaixo da carpa. Já que Luke tem um conteúdo, github, será capaz de vê-lo. Deixe-me escolhê-los e clicar em Adicionar looks na empresa a este repositório. Assim que fizermos isso, o loop realmente receberá um e-mail para aceitar o convite da sun does para ser o colaborador do repositório privado do remetente. Então, deixe-me clicar neste link. Clique em Mutação aceita. Agora, se você for ao painel do Luke, poderá ver esse repositório privado sendo preenchido. Deixe-me clicar nele. Agora posso seguir em frente e traçar esse projeto. Mas não é muito simples pois com o repositório público, temos que realmente autenticá-lo. Deixe-me demonstrar isso para você. Então isso parece computador. Vamos supor que eu esteja dentro da unidade F. E vamos executar o comando git clone e colar a URL e ver o que vai acontecer. Bem, bom abre esse prompt em particular. E há várias maneiras pelas quais podemos nos autenticar. Mas eu gostaria de usar essa opção que diz login com código. Se você escolher entrar com seu navegador, você será direcionado para uma página da web onde será solicitado que você faça login na sua conta do GitHub. Dessa forma, você será autenticado e o processo de clonagem continuará. Mas vamos tentar escolher esse caminho. Quando eu clicar em Login com código, você verá um código que precisamos usar para autenticar. Deixe-me abrir uma janela do navegador primeiro. Eu vou para github.com slash login slash device. Isso nos levará a esta página. Deixe-me copiar esse código, controlar C e controlar V. E clique em Continuar. Clique em Autorizar. nos pedindo para inserir a senha da conta de Luke. Vamos fazer isso bem rápido. Isso é tudo. Nosso processo de clonagem continuou. E agora podemos começar a acessar o aplicativo do banco. Agrupa listas com a opção de hifenizar, mas também mostra as pastas ocultas. Deste ponto em diante, tudo permaneceria como está no repositório público. Mas é assim que você clona um repositório privado. Vejo você em seguida. 68. 0903 Entendendo ramos de rastreamento e ramo padrão: Vamos falar sobre o rastreamento de filiais. Imagine que esse é o estado atual do nosso projeto no GitHub. E agora vamos dizer que eu executei o comando git clone para clonar o projeto no meu computador local. Agora, isso é o que vai acontecer no meu computador local em nenhuma ordem específica. Inicialmente, todos os objetos seriam baixados e seguida, o get criará as chamadas ramificações de rastreamento. Agora, o que é o ramo de rastreamento? Rastreamento de ramificações, uma ramificação local que representa uma ramificação remota. E sempre apontaria exatamente para o mesmo commit. As ramificações remotas estão apontando para lá apenas representando as ramificações remotas. Só para lembrar, uma ramificação é simplesmente um ponteiro para um commit específico. Agora, essas ramificações de rastreamento não serão atualizadas automaticamente. Eles serão atualizados sempre que executarmos certos comandos, como git-fetch e git pull, sobre os quais falaremos nas próximas palestras. E então, por padrão, com a operação de clonagem, o git checkout para o branch padrão, que é o branch principal. E assim, uma ramificação Min local seria criada automaticamente. Na verdade, podemos configurar o branch padrão em nosso GitHub, isso vai explodir nas próximas palestras. Se você se lembra em nossa aula anterior, quando executamos o comando git branch, ele listou apenas o branch principal, mas não o branch do recurso. Bem, essa é a razão disso. Se você quiser ver a ramificação do recurso também, temos que verificar essa ramificação para que uma ramificação de recurso local seja criada por good e possa vê-la. Agora vamos dizer que eu fiz um commit local na ramificação principal como cell, a ramificação de rastreamento permaneceria como está, porque é para isso que até a ramificação principal remota está apontando. Mas o branch principal local seria atualizado para apontar para o commit mais recente em nossa máquina local. Você entenderá a importância de rastrear branches quando explorarmos comandos como git-fetch, git, pull, git push, etc. Outra coisa que você deve ter notado é que todas essas ramificações de rastreamento são nomeadas como origem barra principal ou recurso de origens. Bem, qual é a origem aqui? É essencialmente o primeiro criado pelo get que representa o repositório remoto. Basicamente, sempre que executamos comandos, o winter fornece a URL do repositório remoto. É muito difícil lembrar o URL. E é por isso que criamos esse LES. Para que, em vez de usar a URL, pudéssemos usar esse nome. Em vez disso. Podemos mudar esse nome se quisermos, ou podemos mantê-lo como está. Vamos falar mais sobre isso nas próximas palestras, com certeza. Vejo você a seguir. 69. 0904 Explorando ramos de rastreamento Configurando ramo padrão Entendendo o Origem Head: Ok, vamos primeiro dar uma olhada na lista de ramificações de rastreamento. E o comando para isso é git. Filial. Hyphen r significa Remoto. Aqui você pode ver tanto a ramificação principal quanto a nova ramificação do recurso. E essas são as ramificações de rastreamento que representarão nas ramificações remotas. No GitHub. Você pode dizer que essas são ramificações de rastreamento porque começam com a barra de origem e, em seguida, o nome da ramificação. Você também pode localizar isso no repositório Git. Deixe-me ir para o projeto. E dentro da pasta dot git, você deve conseguir localizar esse arquivo com o nome drifts de hífen compactado. Abra isso. E você pode ver que temos esses dois ramos. E o ponto em comentários específicos. Vamos dar uma olhada no que eles estão apontando. Para isso, deixe-me levantar. Atualmente, estou dentro da filial principal. E aqui você pode ver o HashCode do commit mais recente. É E 0, triplo seis é sete. E estamos na filial principal. E se você notar, o ramo de rastreamento principal está apontando exatamente para o mesmo cometa. Vamos verificar também com o novo branch de recursos. Ele deve apontar para esse commit que começa com 855 D, D2. Vamos voltar e mudar para a ramificação de recurso ou para a nova ramificação de recursos. E com certeza, ele aponta para esse commit com o HashCode 855, duplo D para C. Mesmo que você fizesse um commit local, isso ainda permaneceria como está. Isso só seria atualizado quando realmente executássemos certos comandos como git, fetch, git pull, etc. Vamos explorá-los nas próximas palestras. O branch do Git listaria a lista de branches locais. E qualquer que seja o branch padrão e o GitHub seria verificado não automaticamente sempre que clonamos o projeto, o branch padrão passa a ser o branch principal. A cabeça aqui sempre aponta para a ramificação padrão, que é a ramificação principal. Vamos levantar e dar uma olhada em onde podemos configurar o branch padrão. Se você for para as configurações. Debaixo dos galhos. Aqui você verá que as ramificações padrão, a ramificação principal. Se desejar, você pode alternar para outra ramificação. Por exemplo, posso escolher a ramificação do recurso e clicar em atualizar. Mas não é uma prática recomendada. Vou pular isso. Mas você pode fazer isso se quiser. Dentro do repositório Git. Se você entrar no refs remote origin e der uma olhada no que está dentro do arquivo de cabeçalho, ele deve apontar para o branch padrão, assim. E é isso que estamos vendo aqui. Agora, para criar uma ramificação local para a nova ramificação de recurso, fui verificar essa ramificação. Vamos fazer git checkout. Novo recurso. Agora, se você fizer git branch, ele listará todos os branches locais. E agora também inclui a nova ramificação de recursos. Agora podemos começar a trabalhar nessa ramificação de recursos. Você terá mais clareza sobre o que acabamos falar à medida que progredimos neste capítulo. Vejo você em seguida. 70. 0905 Entendendo a adição remota de origem, edição, exclusão de controles remotos: Vamos falar sobre origem. Origin é como um alias em seu sistema para um repositório remoto específico. Deixe-me explicar o que quero dizer. Existem certos comandos e você precisa especificar o URI do repositório remoto. Como no caso do git push. Vamos falar mais sobre comando git push nas próximas palestras. Mas, essencialmente, o que esse comando nos permite fazer é nos permitir enviar nossos commits locais para o repositório remoto. Bem, esses comandos exigem que entremos para onde queremos enviar nossos commits especificando o URI do repositório remoto. Agora, que tal darmos algum nome a esse ERA para que toda vez que tivermos que executar esse comando, em vez de especificar o ERA inteiro, precisássemos digitar esse nome. Isso vai nos dar muita conveniência. E isso é essencialmente o que é origem. Origin é como um nome abreviado para o estudo de repositório remoto do qual o projeto foi originalmente clonado. Então, em vez de entrar no URI, poderíamos apenas dizer origem, assim. E é Asda. Nós inserimos o URI do repositório remoto. Podemos renomear esse nome para outra coisa. Também podemos adicionar controles remotos adicionais. Quando digo remoto é simplesmente um nome que representa um repositório remoto específico, como podemos até mesmo excluir esses controles remotos. Deixe-me demonstrar o que quero dizer. Se você entrar na pasta dot git, dentro do seu projeto e abrir o arquivo de configuração. Você percebe que temos um controle remoto com a origem do nome e ele aponta para um repositório remoto no campo URL. Isso é exatamente o que é o modo. Então, toda vez que temos que executar o comando, onde seria necessário entrar no CR? Em vez disso, podemos simplesmente inserir a origem do nome. Também podemos renomear isso, mas é claro que não devemos fazer isso diretamente neste arquivo. Em vez disso, vou executar o comando. Vamos fazer isso. Por dentro do Git Bash. Vamos primeiro criar um novo controle remoto. E sim, podemos ter vários controles remotos e há cenários em que podemos exigir vários controles remotos. Vamos falar sobre isso nas próximas palestras. Mas, por enquanto, vamos ver como podemos criar um controle remoto, renomeá-lo e até mesmo excluir um controle remoto. O comando para isso é git remote. Adicione o nome do controle remoto, o nome que você gostaria, a esse repositório remoto. Vamos chamá-lo de temporário, relatório, seja lá o que for. E então você especificará o URI do repositório remoto. Este é apenas um URL fictício que não existe. E se eu clicar em Enter, e se voltarmos ao arquivo de configuração, você verá que há um novo controle remoto criado com o nome pólo temporário, cujo URL é o URL que acabamos de especificar no comando. Deixe-me tentar renomear esse controle remoto. Git remote, renomeie-os como ripple. O nome do controle remoto gostaria de renomear. E então você especificará o nome que gostaríamos de dar a ele. Novo temporário, repo, digamos. E isso vai mudar o nome para esse novo nome. Finalmente, vamos ver como podemos remover um controle remoto. Git. A remoção remota é a opção. Em seguida, você especificará o controle remoto que gostaria de remover. E é isso aí. Isso removeu o controle remoto. Quando executamos o comando clone para clonar um repositório remoto específico, git basicamente criou um remoto para nós. O nome desse controle remoto é origin, cujo URL é o URL que usamos para clonar o projeto. Você entenderá mais sobre controles remotos à medida que progredimos neste curso. Vejo você em seguida. 71. 1001 Entenda o Git Fetch e são usecases: Vamos falar sobre git-fetch. Imagine que esse é o estado atual do nosso projeto tanto no depósito remoto quanto no local. Agora pause o vídeo, tire um minuto e tente entender esse diagrama. Todos vocês renovam isso. Bem, temos apenas alguns comentários no branch principal tanto no repositório local quanto no remoto. E então temos um único commit no branch de recurso no repositório local e remoto, exceto no depósito local, também temos ramificações de rastreamento adicionais que representam as ramificações no remoto repositório. E atualmente eles estão apontando exatamente para os mesmos cometas as ramificações do repositório remoto correspondentes estão apontando. Vamos falar sobre git-fetch. Imagine que há alguns comentários adicionais feitos na ramificação de comentários adicionais feitos na recurso no repositório remoto. Agora, e se eu quiser baixar os objetos que correspondem a esses cometas ao mesmo tempo. Não quero ver todas essas mudanças no meu diretório de trabalho. Agora, você pode estar tendo uma pergunta surgindo em sua mente sobre por que queremos baixar esses objetos? Mas não quero que essas alterações apareçam em um diretório de trabalho. Bem, existem vários casos de uso que isso pode ser útil. Por exemplo, digamos que eu gostaria de comparar meu repositório local com o repositório remoto para verificar quantos comentários o repositório remoto está à frente do meu repositório local no um ramo específico, ou vice-versa. Gostaria de verificar quantos comentários meu repositório local está à frente do repositório remoto em uma ramificação específica? Ou se eu quiser obter o estado exato do repositório remoto como está na minha inscrição local, para começar a trabalhar nele. Ao mesmo tempo. Eu não quero que isso tenha qualquer tipo de implicação no trabalho que eu já fiz localmente. Ou pode ser o caso que eu só queria dar uma olhada se existem ramificações ou tags adicionais, referências que estão presentes no repositório remoto, mas não estão presentes no depósito local. Bem, git-fetch é a resposta para isso. Quando você executa o comando git fetch localmente, ele faz o download todos os objetos adicionais que ainda não estão presentes no seu repositório local. E também atualize essas ramificações de rastreamento para apontar para esses novos commits ou os novos objetos que acabaram de ser baixados com o git-fetch. Agora, neste exemplo, estamos apenas assumindo que temos comentários adicionais e ramificação de recursos. E, portanto, apenas a ramificação de rastreamento da ramificação de recurso é atualizada para apontar exatamente para a mesma confirmação a qual as ramificações remotas apontam. No entanto, se houver comentários adicionais feitos em outras ramificações, as ramificações de rastreamento correspondentes em sua máquina local também serão atualizadas. Agora, o fato de que os branches locais, como o branch principal e o branch feature ainda estão apontando para os commits antigos. Você entrará naquela sala, não terá todas aquelas mudanças recém-introduzidas. Agora, tudo isso pode parecer muito confuso para você, mas nas próximas palestras, você terá total clareza sobre por que precisamos git-fetch e entenderá seu significado. Não consigo encaixar tudo em um único vídeo. Vejo você em seguida. 72. 1002 Git Fetch na Ação Part1 (Variações de comandos verificando status com comandos): Ok, vamos ver como o git fetch funciona. No momento, estou logado como proprietário do repositório. E apenas para sua informação, atualmente tanto o repositório local quanto o remoto são exatamente os mesmos. Nenhum comentário adicional foi feito em nenhum dos lugares. Deixe-me agora ir para o repositório público e fazer um novo commit. Poderíamos fazer isso na ramificação principal ou na ramificação do recurso. Vou simplesmente adicionar um novo arquivo. Eu gostaria de nomeá-lo como talvez Apple dot dx, dy. Não importa se você gostaria de incluir uma pasta e apenas fazer o nome da pasta. Talvez. Como enviar uma nova barra de provedor. Isso criaria uma pasta com o nome Minha pasta dentro da qual terá esse arquivo com o nome apple dot TXT. Eu só gostaria de comentar o arquivo. Clique em Commit. Acabamos de criar um comentário. Deixe-me agora ir em frente e criar uma filial também. Primeiro, deixe-me mudar para o branch principal. Porque isso é de lá. Eu gostaria de criar uma nova filial. Esse tipo no nome da ramificação que eu gostaria de fazer , talvez tenha dois. E então aqui temos a opção de criar um recurso de ramificação para, vamos clicar nele. E isso deve criar um recurso para ramificar. Deixe-me voltar para a nova ramificação de recursos e clicar na lista de comentários. Aqui está o commit que acabamos de fazer, cujo hash começa com E8, AF, qualquer coisa. Agora vamos para a matrícula local. Agora, você precisa imaginar que este é um dos computadores do funcionário, talvez do Sr. Luke, seja o que for. Agora, antes de fazer git fetch, deixe-me executar o comando git log. E observe que estou atualmente na nova ramificação de recursos. Aqui. Como você pode ver, que a nova ramificação do recurso, que é a ramificação local, está apontando para esse commit específico. E até mesmo a ramificação de rastreamento está apontando para esse commit. Agora, uma vez depois de fazer git fetch, ele deve baixar todos os objetos adicionais presentes no repositório remoto e também atualizar esse branch de rastreamento para apontar para esse objeto commit. Vamos ver se isso acontece. Mas antes disso, deixe-me descer mais um comando para verificar os detalhes do controle remoto de origem. Git, remoto, mostrar origem. Isso mostrará as informações sobre o controle remoto de origem. Deixe-me explicar o que está sendo exibido aqui. Temos o fetchone, que está sendo retirado do arquivo de configuração, empurra algo que ainda não falamos. Mas quando usamos o comando push, esse é um URL que deve ser usado para enviar nossas alterações locais. Ramificações de cabeça apontando para a ramificação principal, que tem uma ramificação padrão, como discutimos anteriormente. Aqui está a lista de filiais. Essas são as ramificações que estão disponíveis no repositório remoto. Se você notar, para o novo branch que foi criado no GitHub, Twitter para branch. Ele diz que a próxima busca será armazenada na origem da barra remota. O que isso significa é que, quando buscamos, git criará um branch de rastreamento para o recurso ramificação que está presente no repositório remoto do GitHub. No entanto, o branch principal e o branch do novo recurso, o que já foi rastreado. Aqui está a lista de branches locais configurados para git pull. Vamos falar sobre o bom Pull em breve. Essas são as ramificações do git push. Não temos essa filial aqui porque ainda não buscamos dívidas e não fizemos check-out nessa agência. Agora vamos dar uma olhada no que aconteceria se eu fizesse git fetch. Bem, idealmente, eu tenho que especificar o nome do controle remoto de onde eu gostaria de buscar os objetos. Mas se eu não especificar nada, padrão seria o controle remoto de origem, que já temos. Se você quiser buscar objetos correspondentes a uma ramificação específica em um controle remoto específico. Então, a sintaxe para isso é que você especificará a origem remota nesse caso. E então você apenas especifica o nome da ramificação, por exemplo, novo recurso ou qualquer outra coisa. Se você quiser baixar objetos para todo o controle remoto e todas as ramificações, basta usar a opção. Tudo. Atualmente, temos apenas uma origem de aldeias remotas. Portanto, posso executar esse comando como está sem precisar especificar nada. Então, todos esses objetos adicionais estavam sendo baixados e descompactados localmente. E se você notar, temos esse novo branch, que é um recurso para branch para o qual o branch de rastreamento é criado. E então essa é uma linha importante. A nova ramificação de recursos. Anteriormente, ele estava apontando para esse commit em particular. Mas agora a nova ramificação de rastreamento de recursos, ou a ramificação de rastreamento local, está apontando para esse novo commit. Esse é o commit exato que fizemos no repositório remoto há pouco . Então aqui está. É E8 a F E para E. E isso é exatamente o mesmo. Agora, deixe-me executar novamente o comando remote show origin e ver o que ele tem a mostrar em comparação com o que ele mostrou anteriormente. Bem, agora, se você observar que o recurso para ramificação está sendo rastreado, mas esse branch ainda não está disponível nesta lista. Isso porque ainda não fizemos o check-out para aquela filial. Se eu obtiver o recurso Switch dois, ou você também pode dizer o recurso de checkout do Git também. Nós mudaríamos para esse ramo. E agora, se você executar esse comando, também verá essa ramificação nessa lista. Deixe-me voltar para a nova ramificação de recursos. Sempre que eu mudo para esse branch, você vê esta mensagem que diz que seus branches estão por trás do novo recurso de origem, que é o branch de rastreamento por um commit, que significa que o repositório remoto é um commit à frente de nossa filial depositária local. Também está dizendo que podemos realmente realizar a fusão rápida, sobre a qual falaremos nas próximas palestras. E também está sugerindo que podemos usar o git pull para atualizar seu branch local. Depois de atualizar a ramificação local com boa pesquisa ou com a operação de mesclagem, você verá todas essas novas alterações disponíveis dentro do diretório de trabalho. Países, uma vez que as ramificações locais ainda apontam para todos os commits, seu diretório de trabalho atualmente não é afetado. Se eu fizer git log agora, você só verá que nosso novo branch de recurso local está apontando para esse commit antigo. Anteriormente, se você se lembra, também vimos a ramificação de rastreamento apontando para esse commit. Mas depois de buscar as ramificações de rastreamento agora apontando para novo objeto commit que foi baixado com o git-fetch. Eu vou deixar, te vejo a seguir. 73. 1003 Git Fetch na ação Part2 (Explorando refs FETCH HEAD): Ok, eu mencionei que o git-fetch baixaria os objetos e até atualizaria as ramificações de rastreamento. Digamos que, se eu estiver realmente correto para isso, deixe-me ir ao GitHub e copiar o HashCode do commit mais recente clicando neste ícone. E atualmente estou no novo branch de recursos e no GitHub. Deixe-me ir ao Git Bash e tentar imprimir esse objeto, manter o hífen do arquivo P. E então vou colar o HashCode que acabei de copiar. Assim, podemos ver o conteúdo do objeto commit, o que significa que o git-fetch realmente baixou esse objeto. Se você navegar por essa árvore pai desse objeto cometa, deverá ser capaz de localizar os objetos blob e seu conteúdo correspondente também. Agora vamos ver se os galhos quebrados estão atualizados. Eu mencionei que as ramificações de rastreamento são realmente preservadas no arquivo de planos de fundo. Vamos abrir isso. Aqui. Se você notar, a nova ramificação do recurso ainda está apontando o commit antigo. Agora estou errado ao dizer que as ramificações de rastreamento seriam atualizadas? A resposta é não. Vamos ver o que há nesse diretório específico. Origem remota e novas referências de recursos, origem remota. E deixe-me abrir o arquivo com o nome novo recurso. E aqui você vê o HashCode do commit mais recente. Agora, por que esse código hash está disponível aqui, mas não disponível no arquivo refs, normalmente tende a armazenar referências na estrutura de diretórios. Ele nem sempre é necessariamente armazenado em um arquivo compactado. Use esse arquivo compactado para fins de eficiência. Mas isso não garante como ele não pode nem prever onde vai armazenar as referências. Pode estar no arquivo compactado ou também na forma de uma estrutura de dados. Se ele armazena as diferenças em um arquivo compactado, não precisa criar a estrutura de diretórios apenas para armazenar a referência. É tudo interno para se levantar. E esse é um dos exemplos por que não devemos nos preocupar muito com o quão bom faz as coisas para nós. Só temos que executar os comandos e confiar e entrar nisso. Você também deve ter notado esse arquivo, fetch head, que é criado quando você faz a operação de busca. Vamos ver o conteúdo disso. Agora, é novamente com isso que você não deve se preocupar muito. Mas se você notar que temos três linhas, cada uma correspondendo a ramificação individual, exceto a ramificação de onde desenhamos o comando git-fetch. Todos os ramos marcados como não por muito. Mas, novamente, não vamos tentar aprender tudo porque você pode acabar se confundindo e pode acabar não sendo capaz entender os conceitos reais que são necessários. Mas esse arquivo normalmente é usado por Gibbs. Quando executamos certos comandos como git pull, por exemplo, sobre os quais falaremos nas próximas palestras. Por exemplo. Se você fizer git log, você não conseguirá ver o branch de rastreamento ou dois que vêm nos branches de rastreamento apontando para. Mas se você disser git log e depois buscar a cabeça de sublinhado, por exemplo. Em seguida, ele também listará o objeto cometa para onde as ramificações de rastreamento apontando assim. Então, da mesma forma, temos certos comandos que usariam internamente o arquivo fetch head. Vejo você em seguida. 74. 1004 Mudar para Estado de repo remoto: Agora, com o git-fetch, já que baixamos todos esses objetos, podemos realmente verificar o commit específico e desanexar o que ficou. Dessa forma. Podemos ter o mesmo estado do repositório remoto sem ter que impactar nosso trabalho existente. Deixe-me mostrar o que quero dizer. Deixe-me voltar ao GitHub e mudar para novo branch de recurso e obter o código hash do commit mais recente. Na verdade, os primeiros personagens seriam suficientes. Por dentro do Git Bash. Eu vou dizer git checkout. Existe o HashCode. Então, isso deve trazer nosso projeto para separar esse estado. E, essencialmente, nosso projeto não está exatamente no mesmo estado do repositório remoto. Se você notar, temos esse arquivo, arquivo apple dot TXT, que é o que precisamos. Se você ler esta mensagem, você pode ver que ela diz que você está desapegado no estado. Você pode olhar ao redor, fazer mudanças experimentais e comprometê-las. E você pode descartar todos esses comentários depois voltar para outro branch. Então eu posso ir em frente e fazer alguns comentários. A aplicação ou qualquer outra vesícula experimenta com minhas alterações. E quando eu terminar, posso simplesmente voltar para uma ramificação para que todos esses comentários sejam perdidos. Caso eu queira manter esses comentários, posso usar esse comando para obter qual hífen Z. E então vou especificar um nome para o novo ramo. Portanto, esse comando criaria essa ramificação e teria todos esses comentários em sua cabeça, não apontando para esse commit em particular, não para um ramo específico. E é por isso que é um estado principal destacado. Deixe-me voltar para a nova ramificação de recursos. Novo recurso. E saímos do estado principal destacado. É claro que você não faria mais o arquivo CD apple dot TXT. Agora talvez você possa tomar isso como uma tarefa. Vá para desanexar estado definido, faça alguns comentários antes de voltar para uma ramificação. Certifique-se de que essas alterações sejam, os comentários são preservados em outra ramificação. Desejo-lhe boa sorte com isso. Vejo você em seguida. 75. 1005 mesclando as mudanças usando o FETCH HEAD: Vamos supor que eu gostaria ter todas as alterações do repositório remoto no meu diretório de trabalho. Talvez porque eu gostaria de trabalhar neles, ou talvez seja apenas porque eu gostaria de ter todas as atualizações remotas e depois gostaria de continuar trabalhando em minhas próprias coisas. Agora, uma pergunta para você. O que posso fazer agora para ter todas essas alterações no meu diretório de trabalho. Com git-fetch. Já baixamos todos os objetos. Não precisamos fazer isso de novo. O que mais podemos fazer? Bem, podemos realizar a fusão. Temos a ramificação de rastreamento para novo recurso que aponta para o commit remoto. E também temos o branch local new feature, que aponta para o commit antigo. Se mesclarmos essas duas ramificações, idealmente deveríamos ter todas as alterações em nosso diretório de trabalho, não é? Primeiro, vamos executar o comando git status. Ele diz que suas ramificações estão por trás do novo recurso de origem por um commit e podem ser rápidos, isso é tão bom que nos deu uma sugestão de que podemos realmente executar uma mesclagem rápida. O que também significa que também existe a possibilidade de precisarmos realizar uma fusão de três vias. E podemos muito bem ter conflitos, quais temos que lidar. Já vimos como lidamos com conflitos quando você está tentando mesclar algumas ramificações. O mesmo se aplica aqui também. Agora você pode tentar adivinhar qual comando eu digitar aqui para ter todas essas novas mudanças em nosso diretório de trabalho. Bem, é um comando git merge padrão. Precisamos primeiro fazer push para uma ramificação qual queremos mesclar, neste caso, queremos mesclar as alterações de outra ramificação para a nova ramificação de recurso local. E é aí que eu estou. digitar o comando git merge. E vou especificar o branch de rastreamento, que é o novo recurso de barra de origem. Essencialmente, estamos apenas realizando uma mesclagem rápida nesse caso, em que nosso novo branch de recurso, que é um branch local, agora apontaria para exatamente o mesmo commit que o ramificações de rastreamento remoto apontando para. Mas digamos que você tenha um commit feito em seu repositório local também. Bem, então, nesse caso, você tem que realizar a fusão de três vias. E isso pode criar commit de mesclagem adicional , a menos que você rebase e, em seguida, execute uma mesclagem de avanço rápido. Vamos apertar Enter. Aqui está um resumo do que acabou de acontecer. Nossa nova ramificação local de recursos não está apontando para esse novo commit. O mesmo commit para o qual a ramificação de rastreamento estava apontando. O que acabou de acontecer é uma fusão rápida. E esse é um novo arquivo que veremos em nosso diretório de trabalho. Aqui está. Eu também quero mencionar rapidamente que a alternativa para o comando para isso é git merge, fetch underscore head. Isso fará o mesmo trabalho. E este é um dos comandos que good pode usar o arquivo fetch add. Nós conversamos sobre isso antes. Execute esse comando. Ele diz que já está atualizado porque já tínhamos mesclado as mudanças. Espero que faça sentido. Vejo você em seguida. 76. Usando código do Visusal Studio para Fetch e mesclar: Ok, vamos ver como podemos realizar busca e basicamente escrever o que aprendemos até agora neste capítulo do Visual Studio Code. Antes de tudo, certifique-se de ter o projeto aberto. Se você não vir seu projeto aqui, vá para o menu Arquivo e clique em Abrir pasta. Escolha seu projeto. E você deve estar pronto para ir. Vamos mudar para a seção de controle de origem para executar o git-fetch. Clique neste ícone. E então você vê várias opções. Vá para a seção pull, push e, em seguida, você verá a opção de buscar as alterações. Depois de clicar nele pela primeira vez, você pode receber um aviso perguntando se você gostaria que o Visual Studio Code fizesse isso automaticamente todas as vezes, você pode realmente dizer sim a ele, porque O git-fetch é considerado uma operação segura. E como isso não terá uma implicação no seu diretório de trabalho, você pode executá-lo com segurança sem ter que se preocupar com nada. E depois de fazer isso, você vê um status aqui. No meu caso, vejo um e depois a seta para baixo 0 e depois o vestuário. Não tenho certeza se você é capaz de ver isso. Mas uma seta para baixo significaria que temos confirmações adicionais no repositório remoto, que podem ser mescladas em um depósito local. 0 ou pyro significa que não temos nenhum compromisso adicional ou depósito local de que precisamos carregar nosso push para o repositório remoto. Vamos falar sobre como podemos enviar nossas alterações para o repositório remoto nas próximas palestras. Depois de ter isso, digamos que você decidiu realizar muito. Vamos usar esse plugin de terceiros para isso. E aqui você pode ver que o branch origin new feature está apontando para esse commit e nosso branch local new feature está apontando para esse commit específico. Agora adivinhe? Preciso mesclar essas duas ramificações para ter todas as alterações remotas no meu diretório de trabalho. Então, no Visual Studio Code, preciso clicar com o botão direito do mouse na ramificação que eu quero mesclar. E então você vê essa opção. Mesclar na ramificação atual, nossas ramificações atuais, nova ramificação de recursos, como você pode ver aqui. Então, vamos clicar nele. A propósito, para explicar coisas que trouxeram o projeto de volta ao que era antes da fusão. Então clique com o botão direito nele. Ramo atual magenta. Já falamos sobre esse prompt. É exatamente o mesmo prompt. Nada diferente. Mas não queremos criar um novo comentário. E agora, se você for para a árvore de trabalho, verá esse arquivo, que é o que estamos esperando. 77. 1007 Atualizando referências locais: Digamos que eu gostaria de excluir um branch no repositório remoto. Agora, quais seriam suas implicações? Vamos dar uma olhada. Em primeiro lugar, antes de excluir a ramificação, precisava ter certeza de que todas essas alterações fossem mescladas em outra ramificação. Você também precisa discutir com todas as pessoas que estão ativamente envolvidas na contribuição para esse ramo específico. Antes de excluí-lo. Vamos em frente e excluir um dos ramos. E vou excluir o recurso para ramificar clicando neste ícone. Você também pode excluir uma ramificação remota de sua máquina local, isso explodirá nas próximas palestras. Digamos que este seja um dos desenvolvedores que o computador talvez olhe aqui se eu executar o comando git remote show origin, você notaria que o Git mostrou esse recurso para ramificar como obsoleto. E também nos indicou para usar este comando git remote propenso a remover esse branch, promover o sistema local. Como alternativa, você também pode executar o comando git fetch broom. Com esse comando, o git se conectará ao repositório remoto. Nesse caso, o padrão seria o controle remoto de origem. E, em seguida, ele excluirá todas as diferenças em seu registro local que não estão mais em uso no repositório remoto. Agora, observe que esse comando excluirá apenas as ramificações de rastreamento, mas não as ramificações locais. Sua filial local ainda permaneceria intacta. Então, vamos executar esse comando. Então, isso excluiu o branch de rastreamento. Se você quiser fazer o mesmo a partir do Visual Studio Code, basta clicar neste ícone. Vá para puxar, empurrar seção. E então você encontrará essa opção que diz Fetch prune. Isso faria o mesmo trabalho que com esse comando. Agora, já que você tem uma pizza local para ramificar ainda intacta. E você também pode ter seu próprio conjunto de alterações ou commits no recurso para o branch. Bem, você pode enviar todos esses commits para o repositório remoto. E dessa forma esse ramo seria recriado. Ou você também pode tornar esses comentários parte de algum outro ramo. Vamos falar sobre git push nas próximas palestras. Mas vamos tentar executar esse comando novamente. E não veria mais recurso para ramificar na seção de ramificações remotas. Deixe-me voltar ao GitHub e restaurar esse branch. Mais uma vez. Execute o comando Agora. Em seguida, ele diz que, quando fizermos a próxima busca, ele criaria um novo branch de rastreamento para o recurso ramificar. Vamos fazer isso bem rápido. E você pode ver que o recurso ramificação agora está sendo rastreado essencialmente no mesmo estado do início deste vídeo. Vejo você em seguida. 78. 1101 Entendendo o Git Pull: Vamos falar sobre git pull. Agora diga isso comigo. Git pull é igual a git-fetch mais git merge ou rebased dependendo da opção que escolhermos. Isso é essencialmente o que é bom Pull. Talvez este seja o vídeo mais curto de todo o curso. No entanto, pode não ser tão simples. Vamos falar sobre uma boa atração mais detalhes nas próximas palestras. Vejo você em seguida. 79. 1102 Git Pull em ação e observando o que faz: Ok, vamos dizer git pull em ação. Atualmente, sou um novo ramo de recursos. Deixe-me primeiro experimentá-lo no comando git pull. E diz que já está atualizado. Isso significa que não há comentários adicionais e repositório remoto que ainda não estejam presentes em nosso repositório local. Então, primeiro volte ao repositório remoto e faça um novo commit na ramificação do recurso ou na nova ramificação do recurso. Na verdade, vou editar um dos arquivos. Não importa se você adiciona um novo arquivo ou edita um arquivo existente. O objetivo é fazer um commit. Então, deixe-me ir em frente e clicar neste ícone para editar este arquivo. Não tenho certeza se você é capaz de ver isso. Deixe-me ampliar um pouco. Então, deixe-me adicionar uma linha de texto, algo desse tipo. Realmente não importa o que você adiciona. Clique em Commit Changes. Se quiser obter a mensagem, você pode alterá-la e clicar em Confirmar. Portanto, agora temos commit adicional e repositório remoto, mas isso não está disponível em nossa máquina local. Agora, antes de executar o comando git pull mais uma vez, deixe-me fazer o git log e ver o que ele tem a exibir. Como você pode ver, o novo recurso, bem como o novo recurso de origem, que é o branch de rastreamento, estão apontando para exatamente o mesmo commit. Deixe-me limpar a tela e executar o comando git pull. Como você pode ver inicialmente, ele executou a operação git fetch e descompactou os novos objetos. Então, esses são os objetos que foram baixados do repositório remoto. Há um total de três objetos, que também incluem objetos commit, três objetos, objetos blob, etc. E então ele foi em frente e executou fusão rápida neste caso. Como a mesclagem de avanço rápido funciona nesse caso, não temos nenhum commit em um branch local. E assim o git realizou uma fusão rápida para nós. Agora, se eu fizer git log, você pode ver que o branch local do novo recurso, bem como o branch de rastreamento, estão apontando para esse novo commit, que é exatamente o commit que foi feito apenas um momento atrás. É f phi double d, tanto faz. E é o mesmo HashCode que você vê aqui. Anteriormente, com o git-fetch, nossa filial local não foi atualizada. Mas com o git pull, não apenas buscamos todos os objetos e referências, mas também atualizamos o branch de pontos atualmente verificado. Uma coisa que devo mencionar é que todo o bom comando pull baixaria os objetos e referências pertencentes a várias ramificações ou mesmo remotos. Ele terá muito desempenho na ramificação atualmente verificada. Então, quando fizemos git pull, isso é equivalente a git pull origin porque este é apenas o modo que está configurado atualmente e é o padrão. Mas, se desejar, você também pode especificar o controle remoto de onde deseja buscar objetos. E, em seguida, execute a mesclagem na ramificação de pontos atualmente marcada, que neste caso é uma nova ramificação de recurso. Vejo você em seguida. 80. 1103 Entendendo o Git Pull com mescla de 3 vias: Agora vamos ver o que aconteceria se tivéssemos compromissos feitos tanto no depósito remoto quanto no local. Isso é para simular um cenário em que você pode ter commits feitos em seu repositório local, bem como alguns comentários feitos no repositório remoto podem ser de outros desenvolvedores também. Então, para simular esse comportamento, vamos primeiro tentar fazer um commit em nosso repositório local. Se eu executar o git pull, você verá que nosso repositório já está atualizado. Deixe-me rapidamente, eu fiz um dos arquivos aqui. Vamos editar esse arquivo, por exemplo. Salvou o arquivo, mantém o arquivo. Na verdade, você pode fazer tudo isso a partir do Visual Studio Code, mas é apenas minha preferência pessoal fazer isso no Git Bash. Eu me sinto mais como um programador quando faço isso partir do Git Bash em vez de usar o Visual Studio Code. Então git add apple dot TXT. Boa mensagem de commit. E fizemos nosso compromisso. Vamos ao nosso repositório remoto e vamos fazer algumas edições e o arquivo input.txt. Talvez eu queira adicionar mais uma linha de texto assim. E cometa essas mudanças. Agora você pode esperar o comportamento quando tentamos fazer git pull? Agora, imagine que executamos git-fetch e depois executamos o git merge. O que você espera que aconteça é exatamente o que aconteceria se você executasse o comando git pull. Na verdade, não precisamos especificar o modo. Como você pode ver, isso nos levou a escolher a mensagem. Você consegue adivinhar do que se trata? Bem, esta é a mensagem que o get está nos pedindo para ir para o novo objeto merge commit que ele vai criar. Isso essencialmente executou a fusão de três vias. E o get agora também criará o commit de mesclagem. Digamos que eu esteja feliz com essa mensagem. Eu vou simplesmente fechar isso. E o comando continuaria executando. Desta vez. Se eu fizer git log, você pode ver que o branch local está apontando para o novo commit de mesclagem. Mas a ramificação de rastreamento, como esperado, ainda está apontando para o commit qual sua ramificação remota correspondente está apontando. Esse é o commit que acabamos de baixar do repositório remoto. Agora, e se eu não quiser ter esse commit de mesclagem adicional criado pelo git, rebase é a resposta. E é sobre isso que falaremos em nosso próximo vídeo. Vejo você em seguida. 81. 1104 GIt puxa com rebase e é implicações: Ok, vamos ver como podemos usar o rebase com git pull. Se eu executar o comando git pull, você pode ver que ele já está atualizado. Não há objetos adicionais a serem baixados do repositório remoto. Mas deixe-me tentar fazer um commit no repositório remoto. E 1 segundo, vou simplesmente editar esse arquivo e fazer um commit. Assim. Deixe-me fazer um compromisso em nosso depósito local também. Vou editar esse arquivo usando o editor VI. Você pode usar o Bloco de Notas ou Visual Studio Code. Depende de você. Comece a preparar este arquivo, git commit. Agora vamos tentar fazer a opção git pull rebase e ver o que vai acontecer. Desde a execução da fusão, receba uma palavra. Agora tente realizar o rebase. O que esse comando faz é baixar todos os objetos e confirmar. Essencialmente, nossa ramificação local estaria no mesmo estado que essa ramificação no repositório remoto. E então get reaplicará todos os commits de limite local, um por um. Depois disso. Eu tenho que te mostrar o que eu quero dizer. Então, isso baixou os objetos e também executou o rebase. Mas se você executar o comando git log agora, notará que todos esses comentários até este ponto são essencialmente os mesmos que o comércio que temos no repositório remoto. E ainda por cima, get reaplicou os comentários feitos localmente. Isso é o mesmo que você clonou o projeto do repositório remoto. E então você fez seus commits locais um por um. Isso pode ser melhor visto no Visual Studio Code com o plug-in Git. Então, aqui estamos nós. Como você pode ver, como esses comentários na parte inferior pertencem ao repositório remoto. Você pode perceber isso olhando para a seção automática. Então, todos esses comentários foram feitos pela Centre Corp. E, além disso, rebaseou nossos commits locais em cima dos commits remotos. E é por isso que eles vieram atrás deles. Mas se você notar, não temos aquele commit de mesclagem que tínhamos anteriormente. Mas esse é o propósito do rebase, que é essencialmente não ter esses commits de mesclagem. Rebase basicamente reescreve seus commits e até mesmo o HashCode não seria o mesmo. Por exemplo, se você der uma olhada no último commit que você fez depositário local, o HashCode atual é phi para ser qualquer coisa. Se você fosse dar uma olhada nesse commit exato antes do rebase, o HashCode teria sido diferente. Agora, essa é a razão pela qual todo o rebase faz com que nosso histórico de commits pareça mais linear. Ele não deve fazer rebase se você já tiver todas as suas alterações publicadas no repositório remoto. Vamos falar sobre git push e como podemos enviar seus commits locais para o repositório remoto nas próximas palestras. E então você terá mais clareza sobre o que estou falando. Vejo você em seguida. 82. 1105 Lidar com conflitos com a rebase do Git Pull: Vamos ver o que aconteceria se houvesse algum conflito durante a execução. Para isso, deixe-me editar mais uma vez este arquivo. Vou simplesmente adicionar mais uma linha de código, assim. E comprometa as mudanças. Fizemos edições em um arquivo TXT info dot. Deixe-me ler o mesmo arquivo mesmo no meu repositório local ou no meu computador local. Deixe-me adicionar uma linha de texto, como salvar o arquivo, preparar o arquivo e fazer um commit. Nova edição, arquivo de informações, o que for. Agora deixe-me tentar fazer git pull e devemos ter um conflito. Eu quero usar a opção rebase porque eu não queria ver o commit de mesclagem. Mas depende de você. E como você pode ver, nosso repositório entrou em estado de rebase. Se não fornecermos essa opção, isso estaria mesclando o estado a. A maneira como temos que resolver os conflitos de uma forma ou de outra. Já vimos como podemos resolver conflitos em gets off, merge e rebase em nossos capítulos anteriores. O mesmo se aplica aqui também. Portanto, você pode decidir resolver os conflitos ou usar esse comando para ignorar o commit que está causando conflito. Eu vou fazer exatamente isso. Mas se você quiser editar e resolver os conflitos, você já sabe como fazer isso. O rebase foi bem-sucedido. E quando eu faço git log e não vejo o commit que acabamos de fazer em nosso depósito local. Isso porque fornecemos as opções skip para ignorar o commit que está causando o fim do conflito. Não estamos vendo isso surgir. Mas se você notar as ramificações de rastreamento apontando para o commit mais recente no repositório remoto, assim, espero que faça sentido. Vejo você em seguida. 83. 1106 usando armadilhas e redefinição de difícil: Vamos falar sobre a importância do esconderijo. Digamos que temos um novo comitê e repositório remoto. Para isso. Deixe-me editar o arquivo TXT do ponto de entrada e adicionar uma linha de texto. Assim. Comprometa as mudanças. E digamos que na minha inscrição local, eu vou editar o mesmo arquivo e adicionar uma linha de texto assim, salvar o arquivo e fechá-lo. Agora, se eu for para o Git Bash e se eu fosse executar o comando git pull, observe que eu não encenei ou fiz commit dessas alterações. Não quero comprometê-los porque ainda estou trabalhando nisso. Ao mesmo tempo, gostaria de extrair todas as alterações do repositório remoto para atualizar meu diretório de trabalho. Quando eu executar esse comando, você verá que o Fetch aconteceu com sucesso, mas a mesclagem não aconteceu. Ele diz que suas alterações locais nos seguintes arquivos seriam substituídas pela mesclagem. Para R dxdy, por favor, confirme suas alterações esconda-as antes de mesclar, e, portanto, abortou a operação mod. Essencialmente, fique confuso sobre o que fazer com essas mudanças não confirmadas. Uma solução para isso é, e isso é algo que não é recomendado. O comando que estou prestes a executar pode realmente excluir todo o trabalho que você fez até agora em sua máquina local. E isso também inclui as alterações que acabamos introduzir no arquivo de arte. Obviamente, essa não é uma abordagem recomendada. Mas deixe-me mostrar o comando git reset. Já usamos esse comando no passado. E então você fornecerá a opção difícil. E você especificaria o controle remoto. Vamos ver o que isso vai fazer. Se eu digitar git log, você verá todos os comentários que fizemos localmente ou agora foram para sempre. E é isso que esse comando é muito perigoso. Mas serviu ao propósito de conseguir extrair as alterações do repositório remoto. Se você for aqui, verá que só temos esses dois arquivos. Vamos fazer git pull para extrair todas as alterações do repositório remoto. E agora nosso diretório de trabalho está atualizado. Basicamente, nosso depósito local, bem como repositório remoto, ou exatamente no mesmo estado. Mas essa não é a abordagem recomendada, obviamente. Então, vamos tentar recriar o mesmo cenário mais uma vez. E deixe-me explicar como precisamos lidar com isso. Eu não quero cometer essas mudanças. Mas, ao mesmo tempo, gostaria de obter as atualizações do repositório remoto. Vou voltar ao GitHub e editar esse arquivo mais uma vez. Tanto faz. Vamos tentar fazer git pull agora. E obviamente, novamente, você verá muita coisa sendo abortada. Assim. Então, qual é a solução agora? A solução é o comando git stash. Basicamente, esse comando armazenará temporariamente nossas alterações locais em algum lugar e podemos recuperá-las sempre que quisermos. Por enquanto, já que nossas mudanças locais estão causando problemas. Para extrair as alterações do repositório remoto, deixe-me ir em frente e escondê-las. Como você pode ver, salvo andando por uma árvore e índice de data, progresso de trabalho no novo recurso. Ele está apontando para o arquivo input.txt. Se você abrir em um arquivo TXT de ponto completo agora, não verá as alterações que acabei de introduzir. Agora podemos seguir em frente e fazer o git rebase. Volte para o diretório de trabalho. Você deve estar vendo todas as mudanças remotas. Agora podemos trazer de volta todas as mudanças nas quais eu estava trabalhando anteriormente com o comando git stash, pop. Agora, obviamente, teremos o complexo pode voltar e abrir o arquivo input.txt. Você verá que essas são as mudanças que estão vindo do upstream. Upstream como no repositório remoto. Podemos decidir quais alterações queremos continuar editando esse arquivo, como célula, fechar o arquivo, permanecer no arquivo. Status do Git. Agora, se eu decidir comprometer minhas mudanças, eu posso fazer isso. Mas é capaz de extrair as alterações do repositório remoto sem ter que confirmar nossas alterações existentes. 84. 1201 Configurar tudo para contribuir Adicionar credenciais de configuração de colaboradores: Ok, vamos ver como podemos enviar nossas alterações locais ou os commits locais para o repositório remoto para que todos na equipe possam realmente baixar essas alterações e usá-las todas, começar a andar por cima delas. Agora, para explicar melhor as coisas, vamos limpar as coisas e fazer tudo do zero, como se alguém tivesse acabado de se juntar à equipe e disposto a contribuir para o nosso repositório. Em primeiro lugar, deixe-me fazer login como proprietário do repositório. Eu entrei como Sunda. Esta é a conta Saunders no GitHub. E aqui está o proprietário desse repositório público. Eu vou para as configurações e depois vou adicionar o Sr. Luke como colaborador. Estou esperando alguma contribuição do Sr. Luke para este repositório. Como você pode ver, acabamos de adicionar o Sr. Luke como colaborador. Também excluí todas as ramificações que criamos anteriormente, exceto que deixei a ramificação principal como está. Portanto, atualmente temos uma filial. Todas as ramificações acabaram de ser excluídas. Só para que entendamos tudo limpo e claro. Agora vamos para a conta do Luke. Você pode dizer que esse é o relato de Luke porque tem o tema branco. Aqui está o e-mail que está abaixo recebeu para aceitar o convite para ser um colaborador nesse projeto. Eu vou fazer exatamente isso. A próxima coisa que esse loop precisa fazer é copiar o link HTTPS e clonar o projeto. Com esta finalidade de realmente criar um novo diretório com o nome get. E é aqui que vamos fazer experiências com as coisas. Deixe-me lançar o Git Bash aqui. E vamos clonar o projeto git clone. E então eu vou colar o URL. Isso vai clonar o repositório. Outra coisa que precisamos ter certeza é sobre as credenciais. Vamos digitar o comando git config list option para que possamos ver todas as configurações. E como você pode ver, o nome de usuário é meu nome e o e-mail é algo diferente, não o de Luke. Agora, isso não é obrigatório que você precise atualizar essas credenciais. Mas quais são as credenciais que você dá aqui é o que também se refletiria em objetos concretos. Então, quando você faz commits locais, essas credenciais são registradas e as mesmas credenciais vistas até mesmo no repositório remoto. Depois de fazer push de todos esses commits para o repositório remoto, faz mais sentido ter as credenciais de Luke aqui, porque ele é quem está contribuindo para o repositório. Então, vamos em frente e mudar essas credenciais. Nome do usuário. Vou dar o mesmo nome de usuário conta do Luke no GitHub. Isso também é mudar o e-mail para o e-mail de Luke. Assim. Agora, se você verificar as credenciais, poderá ver que aqueles que estão atualizados. Agora vamos supor que Luke recebeu a tarefa de trabalhar no recurso um. Adivinha o que ele vai fazer? Bem, ele criaria outro ramo e contribuiria com todas as mudanças relacionadas ao recurso um. Vamos fazer isso bem rápido. Vou fazer isso a partir do código do Visual Studio. Se você quiser. Você também pode fazer isso no Git Bash. Vou abrir a pasta com o VS Code. E talvez eu apenas adicione um arquivo adicional. Mas antes disso, precisamos criar uma ramificação. Como você pode ver, atualmente estamos no ramo principal. Deixe-me clicar nele e digitar o recurso um. Ainda não temos essa filial. Não temos esse branch nem mesmo no repositório remoto. Deixe-me ir em frente e escolher essa opção para criar esse branch para nós. O Visual Studio Code criou essa ramificação e também mudou para essa ramificação. Agora deixe-me ir em frente e adicionar um arquivo. Vamos chamá-lo de produto ponto TXT. Linha um, recurso um, algo desse tipo. Vou usar o mesmo texto que a mensagem do commit. Vamos inserir a mensagem e confirmar essas alterações no recurso local um branch. Vamos talvez também fazer mais uma linha de comentário para gostar , então quando copiá-lo e tê-lo como a mensagem para este cometa. Vamos dar uma olhada no gráfico. Como você pode ver, temos o branch principal aqui e o branch feature, que são alguns comentários à frente do branch principal. Vamos supor que Luke tenha feito tudo o que ele precisa fazer para o primeiro recurso. Ele testou todas essas mudanças localmente. E agora ele está disposto a contribuir ou enviar todos esses commits para o repositório remoto. Como ele vai fazer isso é algo que falaremos a seguir. 85. 1202 Criando um ramo remoto e empurrando mudanças usando o Git Bash e o VScode Pushing: Atualmente, temos um branch que foi criado localmente, e até fizemos vários comentários nele. Agora vamos ver como podemos enviar todos esses commits para o repositório remoto. Mas antes de fazer qualquer coisa, isso é muito importante. Você precisa ter certeza de extrair todas as alterações do repositório e do rebase, qualquer que seja a marca na qual você deseja mesclar seu recurso em um branch. Você gostaria de extrair todas as alterações desse branch e reconstruir seu branch de recurso para esse branch. Então, isso terá um histórico de confirmação linear. E se você se deparar com algum tipo de conflito, resolva-os gentilmente para que você não tenha conflitos quando você realmente enviar todas as suas alterações ou carregar todas as suas alterações para o repositório remoto. Já vimos como isso pode ser feito em nosso capítulo anterior. No nosso caso, porém, o branch principal e o recurso no branch não foram divulgados. Não faz sentido para mim realmente fazer um rebase. Agora vamos ver como podemos enviar nossas alterações para o repositório remoto. Vamos primeiro ver como podemos fazer isso a partir do Git Bash. Deixe-me limpar a tela. Então, vamos primeiro entrar nesse diretório. E atualmente estou no ramo de destaque um, como você pode ver aqui. Mas isso realmente não importa para o comando que estamos prestes a executar. Vou dizer git push e entendi dizendo que o recurso de ramificação atual não tem ramificação upstream. Em outras palavras, está dizendo que não temos um branch no repositório remoto para fazer push do branch atual e definir o remoto como upstream. Use esse comando específico. Então, deixe-me copiá-lo e colá-lo aqui. Portanto, esse comando basicamente criaria um branch no repositório remoto, fazendo push de todos os commits que temos nesse branch. Origin é o controle remoto que estamos usando. Se você quiser usar algum outro controle remoto, você pode especificar o nome aqui. E essa opção realmente nos permitirá criar a ramificação no repositório remoto. Este comando também criará a ramificação principal de rastreamento e todo o depósito local para ramificação do recurso um representando a ramificação do recurso um no repositório remoto. Vamos tentar executar esse comando. O Git basicamente compactou todos os objetos e os carregou no repositório remoto. E esse é o URI que ele usou para fazer push de todos os nossos commits. Além disso, também criou uma agência de rastreamento para nós. E também está sugerindo que criemos o chamado pull request. Acessando este URL. Vamos falar sobre pull requests nas próximas palestras. Mas, por enquanto, vamos ao repositório do GitHub e ver se as coisas se refletiram por lá. Deixe-me atualizar esta página. E agora você vê dois galhos. E podemos até mudar para apresentar um ramo como esse. E você vê para cometas aqui, dois deles pertencem ao ramo principal. E, em seguida, há alguns comentários no branch do recurso um. Vamos fazer mais um comentário rapidamente e ver como podemos enviar nossas alterações usando o código do Visual Studio. Então, deixe-me simplesmente adicionar mais uma linha de código ou texto. Assim. Vou usar o mesmo texto que a mensagem do commit. Deixe-me salvar esse arquivo e confirmar nossas alterações. Então, acabamos de fazer mais um commit. Desta vez, vou usar o Visual Studio Code para enviar nossas alterações. Você vê essa opção, empurre. Já que temos apenas um controle remoto, que é a origem do nome. Por padrão, isso foi enviado para o único controle remoto que está disponível. Se você tivesse configurado vários controles remotos, teria a opção de escolher aquele controle remoto para o qual deseja enviar todas essas alterações em 1 segundo. Vamos voltar para levantar. E se eu atualizar a página, você também verá esse novo commit. Pode haver casos em que você queira enviar alterações pertencentes a várias ramificações. Nesse caso, você pode usar a opção para enviar todas as alterações pertencentes a várias ramificações. No entanto, isso não é recomendado. É sempre uma boa ideia lidar com um ramo de cada vez. Também devo mencionar que, na primeira vez que você tentou fazer push de alterações, você pode realmente receber uma solicitação para fazer login na sua conta do GitHub. No meu caso, eu não consegui aquele marrom porque eu já fiz login anteriormente. Deixe-me mostrar o que quero dizer. Deixe-me abrir o Gerenciador de Credenciais no Windows pesquisando no menu Iniciar. E se eu acessar as credenciais do Windows, você verá uma para o GitHub. E isso armazenou as credenciais da conta de Luke. Isso porque eu já tinha feito login e o Windows é capaz de armazenar todas essas credenciais que eu não precise inserir essas credenciais. Toda vez que eu tentava interagir com o repositório remoto. Caso você veja um 403 ao executar o comando, tente remover essas credenciais e tente executar o comando novamente. Então, o que você será solicitado a fazer login mais uma vez, faça login e você deve estar pronto para ir. Deixe-me realmente removê-lo. E deixe-me tentar empurrar as mudanças. E, como você pode ver, recebi essa solicitação de autenticação. Deixe-me acessar a conta GitHub do Luke, github.com, dispositivo de barra de login. Deixe-me inserir esse código aqui. Controle C e controle V, continue. E artrite. Vamos entrar no dispositivo de comida do ônibus foi autenticado. E, claro, como não temos nada para empurrar, considere esta mensagem dizendo que tudo está atualizado. Mas se você voltar aqui, você vai ver esta entrada mais uma vez . Vejo você em seguida. 86. 1203 Entendendo o pedido de tração: Ok, até agora nós criamos um branch local feature e depois fizemos um monte de commits nele. E até enviamos todas essas alterações para o repositório remoto. E aqui estão todas essas alterações no repositório remoto da conta do GitHub. É claro que, como este é um repositório público, qualquer pessoa seria capaz de ver todas essas mudanças. Agora, o loop não pode simplesmente tentar emergir todas essas mudanças no ramo principal. Há certas práticas a serem seguidas. E essas práticas estão em vigor para garantir que o que entra na corrente principal da evolução, que é o ramo principal, seja o código limpo. Então, o que precisamos fazer a seguir antes de realmente mesclar esse recurso que muda no branch principal, é realmente levantar um pull request. Agora, o que é uma solicitação pull? Você pode pensar na pull request como uma solicitação de revisão. Essencialmente, você está pedindo a alguém, em outras palavras, alguém da sua equipe, outros colaboradores ou o proprietário do repositório para revisar todas as suas alterações antes que elas possam ser mescladas no mainstream da evolução, o ramo principal. E você pode estar se perguntando por que isso é chamado de pull request. Essa palavra pode fazer sentido à medida que progredimos neste curso. Mas, por enquanto, você pode pensar nisso enquanto está fazendo uma solicitação para puxar todas as suas alterações de recurso para o branch principal. Então, vamos ver como podemos levantar um pull request. Atualmente, estou na conta do Luke no GitHub. Eu quero ir para esta seção, pull requests. Atualmente, não temos nenhum teste de produto. Vamos criar um clicando nesse botão. Novo pull request. Aqui, vamos preencher todas as mudanças que fizemos na ramificação do recurso um. Como vamos fazer isso é comparando nosso recurso um ramo com um dos outros ramos. Nesse caso, vamos comparar a recurso um com a ramificação principal. Portanto, a diferença entre os dois são as mudanças que introduzimos no recurso no branch. Aqui estou escolhendo o ramo principal como um dos ramos. E o outro ramo seria o recurso de um ramo. Então você vai dizer lista de alterações introduzidas e apresentar um branch porque essas são as mudanças que não estavam presentes no branch principal. E se você tivesse vários arquivos envolvidos em todas essas mudanças, também veria todas essas mudanças aqui. Mas como toda a nossa genialidade entrou em um único arquivo, é isso que você está vendo aqui. E diz mostrando um arquivo alterado. Mas de qualquer forma, aqui está toda a lista de commits, todos os arquivos que foram realmente modificados com todos esses comentários. Vamos em frente e criar pull request. Podemos escrever um resumo rápido do que se trata esse pull request. Apresentando o recurso um, algo desse tipo. Se quiser, você também pode deixar um comentário. E vamos clicar em criar pull request. Agora, na verdade, estamos recebendo essa opção que diz merge pull requests. E se eu clicar em uma dessas opções, isso realmente resultará na fusão todos os recursos alterados no branch principal. No entanto, essa não é uma boa prática. Idealmente, queremos que alguém revise ou mude antes de fundi-los na corrente principal da evolução. Neste momento, Luke é capaz de realmente mesclar todas essas mudanças. Há uma maneira de restringir isso e falaremos sobre isso a seguir. 87. 1204 Entendendo ramos protegidos Aplicando regras de proteção de ramos: Vamos ver como podemos restringir Luke de mesclar o código, a menos que haja pelo menos uma revisão feita por outra pessoa. Para isso, deixe-me ir para alguma conta do GitHub ao anoitecer. Vou para a seção de configurações deste repositório. Eu tenho uma seção de duas filiais. E aqui vou adicionar as chamadas regras de proteção de filiais. Quando eu adiciono pelo menos uma regra de previsão de ramificação para uma ramificação específica, essa ramificação é chamada como uma ramificação protegida. Todas as filiais em que não temos nenhuma regra de previsão de ramificação ou ramificações não protegidas. Basta estar ciente dessas terminologias. Eles serão úteis daqui a pouco. Então, deixe-me clicar neste botão que diz Add Branch production rules. Aqui podemos especificar o padrão de ramificação. Nesse caso, vou simplesmente dizer principal. Portanto, todas as ramificações que combinam com esse padrão teriam todas essas regras de produção aplicadas. Obviamente, somente as regras que habilitamos aqui seriam aplicadas nas ramificações que correspondem a esse padrão. Agora, vamos falar sobre algumas dessas regras nas próximas palestras. Mas, por enquanto, gostaria de colocar uma restrição de que revisão do atlas one deve ser feita antes de mesclar as alterações no ramo principal. Então, vou habilitar essa opção que diz que é necessário um pull request antes da mesclagem. E a descrição diz que, quando habilitamos essa opção, commits do Hall devem ser feitos em um branch não protegido. Então, neste caso, estamos visando o ramo principal. Vou aplicar essa regra de proteção de ramificação na ramificação principal. Então, ao habilitar isso, ninguém seria capaz de se comprometer diretamente no branch principal. O que eles precisam fazer é primeiro confirmar todas as alterações no branch não protegido. Por exemplo, inclua um branch que não esteja protegido e, em seguida, levante um pull request para mesclar todas essas alterações no branch principal. Isso é o que essa opção está dizendo. Se isso parecer confuso, eu pediria que você voltasse e assistisse este vídeo mais uma vez até entender. E então temos essa opção que diz aprovações obrigatórias. E aqui podemos escolher o número de aprovações. Precisamos do número de aprovações de revisão de código necessárias antes de podermos mesclar essas alterações no branch principal. Vamos deixar para o padrão. E vamos clicar em Criar. Mais uma vez, falaremos sobre como as regras de previsão de outros ramos nas próximas palestras. Deixe-me digitar rapidamente a senha. E temos uma regra de previsão de ramificação criada para a ramificação principal. Agora vamos voltar para a conta do Luke no GitHub. Se eu recarregar a página desta vez, Luke não conseguiria mais mesclar essas alterações. E agora está vendo a revisão necessária. Agora, por padrão, qualquer colaborador na equipe ou o proprietário do repositório pode realmente visualizar as alterações. Se você quiser mudar esse comportamento, precisamos realmente fazer uma dessas associações corporativas do GitHub para que possamos obter todo esse controle detalhado. No momento. Não temos controle sobre isso. 88. 1205 Revisão e aprovação das mudanças Trabalhando em comentários de revisão e publicando novas mudanças: Então, vamos para alguns lá em segundo lugar, para revisar as mudanças feitas pelo Sr. Luke. Isso também pode ser a conta de algum outro colaborador neste repositório. Eles também podem revisá-lo. E o que eles precisam fazer para revisar todas as mudanças feitas por Luke é que eles vão para a seção Pull Request. Clique nele. E então poderá ver essa opção, adicionar seu comentário. E aqui eles podem realmente revisar todas as mudanças. Se eles não estiverem satisfeitos com nenhum desses, então eles podem realmente deixar um comentário dizendo, por favor, atualize outra linha, algo desse tipo. E em vez de escolher a opção que é profissional, vou definir alterações de solicitação, o que significa que não estou muito feliz com o código introduzido. Quero trazer essas atualizações com base no meu comentário. Então eu quero revisar novamente. Então, vamos clicar em Enviar avaliação. Na conta do Luke. Ele vai dizer que isso muda ou solicitou. Ele poderá ver a crítica. Assim. Aqui está o comentário feito pelo cilindro. Atualize outra linha. Então, o que Luke vai fazer é realmente trazer todas as mudanças com base no comentário do revisor. Algo desse tipo. Vamos comprometer essa mudança. Podemos promover todas essas mudanças. Ou, como alternativa, podemos clicar nesse botão que diz alterações de sincronização. Então, isso vai impulsionar nossas mudanças. E se houver alguma mudança a ser puxada para cima, faça também. Vamos voltar ao GitHub. E essas mudanças deveriam estar presentes e futuras em um ramo. E como você pode ver, podemos ver esse novo commit. Agora não precisamos fazer outra solicitação de pesquisa. A solicitação de pool existente seria preenchida automaticamente. Vamos voltar à conta do remetente bem rápido. E Nelson Lord pode ver uma atualização dizendo que um novo commit foi feito. Normalmente, é bom enviar um lembrete por e-mail ou algo assim. Ou pode haver algum tipo de ferramenta que enviaria automaticamente um lembrete por e-mail para todos os revisores. Assim, o remetente visualizaria todas as mudanças e ele revisaria todas as mudanças e assumiria que ele está muito feliz com as mudanças, vai protegê-las e dizer algo desse tipo e vai aprovar as mudanças como célula. Vamos voltar para a conta do Luke. Agora olhe no bar da marcha. Vamos falar sobre isso A seguir. 89. 1206 Explorando as opções de fusão Understading Squashing commits Apagar ramo remoto: Agora que a revisão está concluída e as alterações aprovadas por um dos revisores, Luke está pronto para ir em frente e mesclar todas essas mudanças do recurso um no ramo principal. Se você pegar a licença de organização do GitHub, terá um controle mais refinado. dois últimos podem realmente mesclar os pull requests no momento com a versão gratuita dos colaboradores do seu projeto seria capaz de mesclar os pull requests, incluindo o indivíduo que aumenta o pull solicitações. Então, neste caso, Luke está realmente tentando mesclar seu próprio pull request. Em projetos em tempo real. Esse seria um dos líderes da equipe ou alguma pessoa autorizada a fazer esse trabalho. Vamos dar uma olhada em todas as opções que temos aqui. Podemos criar um commit de mesclagem. E, como o nome sugere, isso basicamente criará um novo commit de mesclagem no branch principal. E isso aponta para alguns compromissos dos pais. Um pai seria o último commit do branch principal, o outro pai KM, seria o último commit do branch do recurso. Já discutimos sobre mesclagem de commits. Não preciso reiterar mais uma vez. E sem mencionar entrar no histórico de commits seria mantido, o que significa que você também pode ter todas as histórias de cometas espaguete. Se você não quiser ter um histórico de commits spaghetti e não quiser criar um commit de mesclagem adicional. Então você pode ir com a terceira opção, que diz descontos e mesclagem. Portanto, todos os quatro commits desse branch, que é um branch de recurso, serão rebaseados e, em seguida, adicioná-los ao branch base para que o histórico de commits no branch principal pareça mais linear. Também temos uma terceira opção que é squash e merge. E como diz a descrição, os quatro commits desse branch serão combinados em um commit no branch base. Isso é tão bom quanto você está fazendo um novo commit no branch principal com todas as mudanças combinadas do branch do recurso um. Essa pode ser a solução ideal se você tiver vários commits. E faz sentido combiná-los juntos. No nosso caso, quase não fizemos nenhuma alteração em cada um de nossos commits, apenas alteramos uma única linha de texto. Então, talvez essa opção seja a coisa ideal para nós. Essencialmente, se você tiver vários commits em que fez pequenas alterações, e se você acha que eles podem ser combinados como um único commit, podemos usar essa opção. Não tenho certeza se você é capaz de se lembrar, mas quando falamos sobre rebase interativo, tivemos a opção de esmagar alguns dos commits. Basicamente, quando você está realizando rebase interativo, você pode listar todos os commits que deseja esmagar ou combiná-los juntos. Então, digamos que você tenha dez commits em seu branch de recurso. Você pode esmagar quatro deles ou três deles ou o que fizer sentido para você usando rebase interativo. Se você não se lembra, eu recomendaria que você assistisse novamente à interação com a melhor palestra sobre as mesmas. Por enquanto, vamos com essa opção, rebase e merge. Na maioria dos casos, seria merge commit ou Rebus e merge dependendo de seus requisitos. Também devo mencionar que como já havíamos reformulado o branch do recurso para o commit mais recente branch principal antes de realmente aumentarmos o pull request, resolvemos todos os conflitos em potencial antes de realmente aumentar os pull requests. E é por isso que, neste momento, você não está vendo nenhum conflito. Mas pode haver casos raros em que alguém da sua equipe possa ter introduzido alterações no seu branch principal enquanto o pull request ainda está ativo, o que pode realmente criar conflito. Como você lida com esses conflitos é algo sobre o qual falaremos mais tarde. Por enquanto, vamos em frente e Rebus e mesclar. E como tarefa, você também pode experimentar essas duas opções. Bem direto. Vamos clicar em descontos e mesclar. Vamos confirmar. Portanto, a pull request foi mesclada e fechada com sucesso. E estamos prontos para seguir em frente e excluir esse branch específico. Podemos excluí-lo do GitHub ou também podemos fazer o mesmo em nossa máquina local. Deixe-me mostrar o que quero dizer. Deixe-me abrir o Git Bash aqui. Atualmente, estou dentro do projeto. Deixe-me agora ir em frente e excluir a ramificação remota. E o comando para isso é git, push origin, name of the remote. E então você vai usar dois pontos seguidos pelo nome da ramificação que você deseja excluir no servidor remoto. Recurso um, no nosso caso, vou apertar Enter. E isso deve excluir o recurso na ramificação no repositório remoto. Vamos voltar. E como você pode ver, agora só temos o ramo principal. E aqui está a lista de commits nele, que agora também inclui todos os comentários feitos no recurso um. Se eu fizer git branch, você ainda verá o branch local. Deixe-me pegar o nome correto. Ainda temos a filial local. Vamos em frente e excluí-lo também. Git branch, hífen D, recurso um. Ok, para mudar para um ramo diferente. E vamos executar novamente o comando. E a ramificação foi excluída. Como o recurso remoto nas ramificações foi excluído, até mesmo a ramificação de rastreamento correspondente não está mais disponível. Vejo você em seguida. 90. 1207 O que Git Pull realmente faz: Toda vez que você tentar enviar suas alterações locais para o repositório remoto, git realmente tentará mesclar nossas alterações locais com o mesmo branch no repositório remoto. Mas ele fará isso apenas se resultar em uma fusão rápida ou não conseguirá empurrar nossas mudanças e, em seguida, uma maneira de contornar isso para que seja feito. Eu sei que isso parece confuso e é por isso que dediquei este vídeo para falar sobre isso. E para explicar melhor as coisas. Na verdade, vou fazer tudo do zero. Deixe-me acessar a conta do remetente e criar um novo depósito. Vamos dar um nome aleatório. Realmente não importa. Vamos mantê-lo temporariamente de qualquer maneira. E vamos também adicionar um desses arquivos apenas para que tenhamos um commit no branch principal uma vez depois de criarmos esse repositório. Deixe-me também adicionar o recurso em que uma ramificação é criada. E então vamos fazer um commit e apresentar uma ramificação também, talvez editando o arquivo leia-me. Linha um, recurso um. Vamos chamá-lo de linha para. Realmente não importa. Vamos fazer o commit. Vamos para Configurações e Adicionar Mr. Luke como um dos colaboradores. Tudo bem, agora vamos para a conta do Luke. Então, Luke acabou de receber um convite para contribuir com esse projeto. Vai ver esse convite e aceitar o convite. E então ele vai clonar o projeto em sua máquina local para começar a contribuir. Em uma das pastas. Vou abrir o Git Bash. E vamos fazer git clone neste projeto. Vamos entrar nessa pasta. E se eu fizer git branch, tudo o que você vê é que temos uma filial remota de Rachman do Maine, bem como o recurso um, mas não temos o branch local off feature one. Então, para obtê-lo, vamos mudar para apresentar um branch ou checkout para apresentar um branch. Então, agora, terá essa filial local criada. E atualmente estamos em destaque em um ramo. Na verdade, vamos fazer o resto do código do Visual Studio. Então, vamos abrir esse projeto com o VS Code. E digamos que eu gostaria de fazer um comentário no novo recurso um ramo. Portanto, estamos atualmente em destaque em um ramo. Deixe-me talvez desta vez adicionar um arquivo, vamos chamá-lo de um ponto dx, dy. Eu vou para o controle de fontes, dou uma mensagem para o commit e confirmo nossas alterações. Agora imagine que outra pessoa na equipe que também está trabalhando no mesmo branch, fez algumas alterações no repositório remoto no mesmo branch para simular esse comportamento. Vamos voltar para a conta do remetente e realmente fazer um commit no recurso um branch como se alguém tivesse enviado as alterações para esse branch. Deixe-me adicionar outro arquivo, talvez dois pontos TXT. E vamos comprometer nossas mudanças. Agora, basicamente, ambos são recursos locais na ramificação e sua ramificação remota correspondente ou não divergem. Vamos ver o que aconteceria se eu tentasse enviar nossas alterações locais para o repositório remoto. Git push, podemos especificar o remoto e apresentar um branch. Mas se você usar esse comando, ele será o comportamento padrão de qualquer maneira. Então, vamos empurrar nossas mudanças e ver o que vai acontecer. Como você pode ver, temos um erro que diz que falhou ao enviar algumas referências para esse repositório e atualizações para rejeitadas porque o conteúdo remoto funciona que você não tem localmente. Então, como eu disse antes, quando enviamos nosso kit de alterações locais na verdade, tentaremos mesclar ou alterações locais com o mesmo branch no repositório remoto. Nesse caso, isso não está resultando em uma fusão rápida e é isso que gets não impulsionou nossas mudanças. Então, o que podemos fazer aqui agora é usar o comando git pull. E, por padrão, ele também tentará realizar a mesclagem dessas duas ramificações em nossa inscrição local. Então, deixe-me tentar git pull para puxar as mudanças. Também podemos fazer o mesmo com o código do Visual Studio. Se você quiser. Por exemplo, posso dizer git pull de lá ou daqui. Vamos tentar ver o gráfico agora. E como você pode ver, git tentou executar o recurso de mesclagem em um branch com nosso professor local um branch. Portanto, esse é essencialmente o commit de mesclagem. Agora, se você tentar executar uma operação push, ela deverá ser bem-sucedida. E então devemos ser capazes de ver esse commit de mesclagem no repositório remoto também. Mas se você quiser se livrar desse merge commit, você já sabe o que fazer. O rebase é a resposta. Então, vamos tentar refazer o rebase do nosso branch atual, que é o recurso um branch sobre a mudança recente do repositório remoto. Essencialmente, estou tentando rebasear um recurso local uma ramificação com a ramificação de rastreamento remoto, que representa essencialmente o recurso remoto de uma ramificação. Portanto, esse é o commit para o qual as ramificações de rastreamento apontam. Vou clicar com o botão direito nele. E então eu vou escolher essa opção rebase, ramo atual neste comitê. E vamos rebase como parte do renascimento, como discutimos anteriormente em uma de nossas palestras anteriores. Ele também eliminará todos os commits de mesclagem. Porque, essencialmente, estamos reescrevendo todo o histórico de commits. E isso meio que resolve o problema de não ter muitos commits. Então, agora temos um histórico linear de commits. Estamos prontos para ir e impulsionar nossas mudanças. Desta vez. Isso resultará na mesclagem rápida do recurso local na ramificação e do recurso remoto em uma ramificação. E, portanto, não devemos ter nenhum tipo de problema ou algo assim. Mas, de modo geral, você deve ter cuidado com a operação de rebase. E há certas práticas recomendadas a serem seguidas, que é o que discutiremos nas próximas palestras. Não há problema em ter muito comprometimento. Você também pode enviar seu comentário de mesclagem, se desejar. E, de fato, é uma das escolhas populares porque o rebase pode realmente bagunçar as coisas. O que é novamente, algo sobre o qual falaremos nas próximas palestras. Mas, por enquanto, estamos prontos para impulsionar nossas mudanças. E é bem-sucedido ir para o repositório remoto. Agora, mude para o recurso de um ramo. Deveria estar vendo todos esses comentários, incluindo o commit local que fizemos anteriormente. Vejo você em seguida. 91. 1208 Resolver conflitos no GitHub da maneira correta Força empurrando mudanças e suas consequências: Vamos ver como podemos lidar com conflitos quando estamos tentando mesclar recurso um no mainstream da evolução, o ramo principal. Atualmente, estou em destaque em um ramo e, como você pode ver, temos todos esses quatro commits de nossas palestras anteriores. O que vou fazer agora é levantar uma solicitação pull para uma solicitação pull para todas as mudanças que introduzimos in vitro, uma solicitação pull levantada por ramificação . Agora estou realmente pronto para realizar qualquer uma dessas operações. Também posso realizar reparos e muito mais porque nenhum novo comentário foi feito na ramificação principal e não há como isso causar conflitos. Mas e se depois de levantar o pull request, alguém introduzir novas alterações no branch principal, o que pode estar causando conflitos sem alterações no recurso um. Para simular esse comportamento. Deixe-me voltar para a ramificação principal e editar esse arquivo. Se você se lembra, em um dos comentários in vitro e branch, atualizamos o arquivo ReadMe. Portanto, se eu atualizar esse arquivo novamente no branch principal, isso deve nos causar um conflito. Então, deixe-me clicar neste arquivo e adicionar algum texto assim, e confirmar as alterações. Agora vamos voltar para a pull request e ver se agora podemos executar o Freebase. E agora você vê um aviso que diz que o ramo complexo e isso deve ser resolvido. Podemos resolver conflitos aqui, mas não é uma abordagem recomendada. Resumindo, isso vai complicar um pouco as coisas. Basicamente, se você olhar para a história do chametz, isso vai confundi-lo. Há uma maneira melhor de lidar com isso. E é isso que vou mostrar a vocês agora em nossa máquina local como ele que isso parece computador. Em primeiro lugar, vamos trazer todas as mudanças no branch principal. Então, deixe-me mudar para o branch principal e obter um novo commit. Agora vamos tentar rebasear nosso recurso um branch sobre esse novo commit. Esse é um procedimento padrão que seguimos em uma de nossas palestras anteriores. O que você está baseando alguém para voltar ao recurso um? Clique com o botão direito do mouse neste commit e escolha esta opção que diz rebase current branch neste comitê. Isso deve nos dar conflitos. E, como esperado, temos conflitos. Isso significa dispensá-lo. Então, vamos resolver esses conflitos. Talvez desta vez eu gostaria de aceitar as duas mudanças. Salve o arquivo, deixe-me declará-lo e clicar em Confirmar. Isso basicamente criará um novo commit com todos os conflitos de resultado. Vamos inserir alguma mensagem. Eu gostaria de manter como está. Depois de fechá-lo. Isso deve rebasear qual ramificação em cima desse novo commit. Assim. Então, agora todos os commits que estão no branch ou vistos em cima desse commit. Agora vamos tentar enviar todas essas alterações para o repositório remoto e ver o que vai acontecer. Deixe-me limpar a tela. Também podemos fazer o mesmo com o Visual Studio Code. Deixe-me digitar o comando git push e ver o que vai acontecer. Em 1 segundo, recebemos esse ditado hetero, falha ao enviar algumas referências para o repositório remoto. Isso porque, com o rebase, insira o histórico de commits que foi reescrito e não corresponde ao histórico de commits que temos no repositório remoto. Agora fique bom que nosso recurso local, um branch e seu recurso correspondente , um branch no repositório remoto, ou ambos divergiram. E, portanto, não está nos permitindo forçar nossas mudanças. Então, como enviamos nossas alterações agora para o repositório remoto? Bem, podemos usar a opção force. Então, desta vez com git push e quando fornecer a opção force. Agora, o que isso vai fazer? O sinalizador force fará com que o branch dos repositórios remotos corresponda o branch dos repositórios remotos corresponda ao seu branch local. E isso excluirá todas as alterações anteriores que possam ter ocorrido desde o último marcador. que também significa que, se houver várias pessoas trabalhando no mesmo ramo e se alguém tivesse contribuído com suas alterações para o mesmo ramo, todo o trabalho seria perdido, que é às vezes não é desejável. Portanto, há casos em que você não deveria usar a opção force. Vamos falar sobre tudo isso e melhores práticas nas próximas palestras. Mas, por enquanto, isso vai fazer o trabalho para nós. E se você voltar para o repositório remoto, perceberá que agora podemos realizar rebase e mesclar ou até mesmo outras duas opções. Vamos dar uma olhada no histórico de commits bem rápido. Para ir para apresentar um ramo. Dê uma olhada na lista de commits. Portanto, temos todos esses comentários feitos no branch do recurso um empilhado em cima dos comentários do branch principal. Agora podemos ir em frente e realizar descontos e mesclar. Também podemos dissolver o complexo e o GitHub, mas ele fará coisas estranhas como Robeson, o branch principal em cima do qual um branch para fazer as coisas. E isso pode criar muita confusão. Mas essa geralmente é a prática comum seguida para resolver o conflito. Agora não faz sentido ter o galho por perto. Para que eu possa excluí-lo. Espero que faça sentido. Vejo você em seguida. 92. Estratégia de divisão e conqr: Vamos ver como podemos lidar com as consequências negativas do uso da opção de força. Quando você usa o comando push. Eu mencionei que quando você usa a opção force, o histórico de commits no servidor remoto será sobrescrito à força pelo seu próprio histórico local. Agora, há algumas consequências com isso. Número um, podemos ter vários desenvolvedores trabalhando no mesmo branch e podemos correr o risco de perder todos os commits feitos por eles que vieram após sua última pesquisa. E em segundo lugar, o mais importante, quando você faz o Rebus e depois força, empurra suas alterações, isso pode realmente criar uma bagunça porque todos os outros membros da equipe podem ter baixado o projeto e talvez tenha saído para aquela filial. Essencialmente, quando você faz o rebase e faz uma pausa no push suas alterações não apenas estão lendo o histórico de commits, mas também seus códigos hash. E todos os membros da equipe que podem ter baixado o projeto e Chet dot para esse branch podem ter um conjunto diferente de histórico comum em comparação com o que está lá no repositório remoto. Isso vai criar muita bagunça. Então, para evitar isso, temos uma estratégia chamada dividir e conquistar. Deixe-me explicar o que quero dizer. Digamos que essa seja a ramificação principal e essa seja a ramificação de recurso no repositório remoto. Agora vamos supor que alguns desenvolvedores estejam dispostos a contribuir para esse ramo. Em vez de ambos estarem contribuindo para esse ramo. Agora teremos algumas sub-filiais e cada uma seria de propriedade de um desenvolvedor individual. Tanto esse dólar por contribuiria com seu próprio conjunto de mudanças em suas próprias sub-agências. E como eles estão andando em seu próprio galho, as alterações feitas em um galho não terão nenhum impacto no outro ramo. Por exemplo, um dos desenvolvedores pode querer rebase e forçar o commit todas essas alterações em seu próprio branch. E isso não terá nenhum tipo de impacto na outra filial de propriedade do desenvolvedor. E uma vez que um dos desenvolvedores terminar tudo o que precisa fazer, eles podem mesclar todas as alterações na ramificação de um recurso. E então o outro par de dólares rebasearia sua filial em cima do recurso um ramo e, eventualmente, mesclaria suas mudanças também. E se houver alguma mudança que qualquer um dos dólares mais possa ter perdido, eles podem criar outra filial e trazer todas essas mudanças. E então, é claro, mescle essas mudanças no recurso um ramo. Isso é chamado de estratégia de dividir e conquistar. E isso pode evitar os efeitos colaterais que podem surgir quando você forçar suas mudanças. No entanto, pode haver casos em que essa abordagem pode não ser viável. Nesse caso, temos uma alternativa para, e é sobre isso que falaremos a seguir. Mas talvez você possa encarar isso como uma tarefa. Tente criar algumas sub-ramificações do recurso um ramo e tente seguir a abordagem de divisão e conquista. 93. Resolução de conflitos por mesclar o ramo principal: Ok, vamos ver como podemos lidar com conflitos mesclando os ramos sem ter que usar a opção de força, ou seguindo a abordagem de dividir e conquistar. Para isso, vamos primeiro tentar criar outro conflito. Como já excluímos o branch feature one, vamos criar um novo branch para introduzir novos conflitos. Vamos chamá-lo de novo recurso. Tanto faz. Vou criar esse ramo. E deixe-me editar um desses arquivos. Digamos que eu gostaria de editar um arquivo TXT de um ponto. E vou simplesmente adicionar o nome do ramo como célula. Comprometa as mudanças. Deixe-me voltar para a ramificação principal. E vamos tentar editar o mesmo arquivo mais uma vez, para que tenhamos conflito. Vamos apenas dizer main e comprometer as mudanças. Agora vamos para pull requests e tentar criar um novo pull request. Então, estamos comparando o branch principal com o novo branch de recurso. E aqui estão as mudanças. Deixe-me ir em frente e criar o pull request. Como você pode ver, estamos recebendo uma mensagem que diz que esse ramo é complexo que deve ser resolvido. E também temos a opção de resolver conflitos. quão bom isso nos permitiria resolver os conflitos é realmente mesclando o branch principal no branch do recurso. Agora, isso pode realmente surpreendê-lo, mas realmente funciona. Deixe-me mostrar o que quero dizer. Deixe-me clicar em resolver conflitos. É como se estivéssemos em um estado de fusão em que os conflitos precisam ser resolvidos. E podemos resolver os conflitos da mesma forma que os dissolvemos em nossa máquina local quando estamos tentando mesclar filiais. Então, nesse caso, GitHub está tentando mesclar o branch principal no novo branch de recurso. E isso basicamente traria todas as mudanças do branch principal ou todos os comentários do branch principal para o branch do recurso. Gostaria de manter as duas mudanças. E vou clicar nesse botão que diz Mark. Como resultado. Nós vamos para a fusão. Isso criará um commit de mesclagem e apontará para alguns commits pais. O último comentário da ramificação principal e o último commit da nova ramificação do recurso. Muito parecido com o que fizemos em nossa máquina local quando estamos tentando resolver os conflitos. Enquanto margem. Aqui você pode ver que acabamos mesclar o main no novo branch do recurso. E isso resolveu o problema. Para voltar ao repositório, os commits no branch principal permaneceriam assim. Deixe-me mostrar a você. Mas, se você for para o novo branch de recurso, ele terá todos os commits nos comentários que foram feitos e no novo branch de recurso e também no commit de mesclagem. Se você entrar nisso, verá que tem dois pais. Um pai é o último commit do branch principal e o outro é o novo comentário que acabamos de fazer no branch do recurso. Portanto, esse instantâneo de commit de mesclagem teria alterações introduzidas em ambas as ramificações. E é por isso que podemos ver todos os commits pertencentes aos dois branches. Agora, não tenho certeza se isso está realmente confundindo você, mas isso é bem direto. Se você não entende isso, então está tudo bem. Já discutimos algumas maneiras de resolver os conflitos. Nas últimas palestras. Você pode seguir essa abordagem ou também pode seguir essa abordagem. Você também pode fazer o mesmo mesmo em seu depósito local. Basta verificar o projeto e tentar mesclar o branch principal em seu branch feature one, resolver os conflitos para que você tenha um histórico de commits semelhante em sua máquina local. E então você fará push de todos esses commits para o repositório remoto com o comando push padrão. Vamos voltar para o pull request. Agora não temos mais os conflitos. Essa ramificação não tem conflitos com a ramificação base. E estamos prontos para seguir em frente e realizar a fusão. No entanto, você não pode realizar rebase. Você não pode executar o rebase porque, como você já sabe, rebase vai reescrever o histórico de commits e até mesmo se livrar dos commits de merge. Nesse caso, não faz sentido fazer isso. Isso parece confuso. Então, lembre-se de que ele não pode realizar rebase. Nesse caso. Se você tentar executar o rebase, ele diz que essa ramificação não pode ser rebaseada devido ao complexo. A mensagem não é muito clara, na verdade, mas espero que você tenha entendido. Mas podemos mesclar as mudanças e fazer com que elas se fundam. Agora podemos nos livrar da nova ramificação de recursos. E essa é a forma alternativa de resolver o complexo. Vejo você em seguida. 94. 1301 O que é Forking e por que Forking: Vamos falar sobre for king no GitHub e seu significado. Imagine que temos um projeto de código aberto com o nome open app no repositório GitHub. E diga que isso é de propriedade do Sr. Sunda. Agora, quando eu digo que este é o projeto de código aberto, você pode esperar centenas ou até milhares de desenvolvedores em todo o mundo que estão dispostos a contribuir para este projeto. Agora imagine a quantidade de trabalho que foi feito precisa ser feito para gerenciar os colaboradores. Se o cilindro gerenciar centenas ou milhares de colaboradores, torna-se um trabalho por conta própria. Por exemplo, toda vez que alguém quer contribuir, seja uma pequena contribuição ou uma grande contribuição, ainda é necessário adicioná-lo como colaborador. Em segundo lugar, se diversos usarem a versão gratuita do GitHub, então essencialmente todos os colaboradores, teremos o privilégio de mesclar seu código no branch principal. Agora imagine algum dólar iniciante por quem está começando a programar. Entregue algum código e módulo dessas alterações na ramificação principal sem fazer testes adequados. Obviamente, isso vai criar muita bagunça. Então, precisamos de uma solução para esse problema. Bem, a solução é bifurcar. Então, o que exatamente é bifurcação? Imagine que o Sr. Luke quer contribuir para este projeto e ele não foi adicionado como colaborador neste projeto. Então, o que Luke vai fazer é com apenas um clique de um botão, foi para folk este repositório em sua própria conta do GitHub. Você pode pensar em trabalhar como clone. Mas em vez de cloná-lo na máquina local, isso vai acontecer na salva do GitHub na conta de Luke. Nesse caso, Luke e renomeie este projeto para qualquer que seja o nome de sua escolha, ou ele também pode manter o mesmo nome. Realmente não importa. Como uma convenção de nomenclatura padrão. O repositório padrão é chamado de origem e o repositório original é chamado de upstream. É claro que você pode ligar para eles com qualquer nome de sua escolha. Mas essas são as convenções de nomenclatura típicas que seguimos como desenvolvedores. Então, sempre que digo origem, estou me referindo ao repositório bifurcado. Sempre que digo upstream, estou me referindo ao repositório original de onde temos quatro. Agora olhe, vamos fazer um repositório bifurcado de escritório clone, mesmo em sua máquina local. Em seguida, ele apresentará todas as alterações que precisa introduzir e enviará todas essas alterações no repositório bifurcado. Enquanto isso, se houver alguma nova atualização no depositário original, olhe e realmente puxando todas essas alterações para seu depositário local e empurre todas essas mudanças ou novos commits para o seu repositório bifurcado. Dessa forma, o repositório padrão permanecerá atualizado, mas as mudanças recém-introduzidas nos depositários originais depois Luca terminar com quais são as mudanças que ele deseja introduzir. E, claro, após um teste adequado , haverá um pull request, pedindo a alguns que aceitem todas essas alterações e façam merge dessas alterações no branch principal do repositório original. Portanto, esse navio lá dentro não precisa ter acesso de escrita para começar a contribuir. Essa abordagem de contribuir para um projeto bifurcando o repositório não é boa apenas para o proprietário do repositório, mas também o dólar mais um para contribuir com o projeto. Aqui estão algumas das vantagens para os desenvolvedores usarem a bifurcação. Em vez de contribuir diretamente para o repositório original. Caminhar permite que qualquer pessoa contribua para um projeto sem ter o acesso certo. Porque eles podem simplesmente criar uma bifurcação de um projeto, introduzir todas as alterações, testá-las e, em seguida, criar uma pull request. Eles podem experimentar livremente as mudanças sem afetar o projeto original. Em alguns casos, pode haver várias pessoas que queiram contribuir coletivamente para um projeto específico. Nesse caso, é sempre melhor bifurcar o depósito original, excluir todas as alterações, fazer testes de integração. E uma vez que eles terminem, eles podem aumentar a pull request, solicitando que o depósito original ao proprietário extraia todas as alterações e mescle essas alterações no branch principal. Caminhar permite que você use o projeto de outra pessoa como ponto de partida para sua própria ideia. Muitos softwares ou aplicativos comerciais foram originalmente iniciados com um projeto de código aberto. Eles apenas trabalham em todos os projetos de código aberto existentes e introduzem mudanças além disso e vendem para seus clientes com a licença comercial. E, por fim, você não precisa esperar pelo acesso correto. Imagine que você está escrevendo um e-mail para o proprietário posterior pedindo o eixo direito, e então você espera para sempre pela resposta. Bem, com a bifurcação, você pode contribuir diretamente para o projeto e solicitar pull de corrida sem ter que o acesso correto ao depósito original. Vamos ver toda essa inação e muito mais nas próximas palestras. Vejo você em seguida. 95. 1302 Forçar um repositório público e cloná-lo em nossa máquina local: Ok, vamos ver como podemos bifurcar um repositório para começar a contribuir. Agora imagine que este é o computador de Luke e ele está disposto a contribuir com um dos projetos de código aberto disponíveis online. Então, deixe-me acessar a conta do Luke no GitHub. E aqui está. E suponha que esse é o projeto para o qual Luke está disposto a contribuir. Este projeto é de propriedade do Sr. cylinder and look, não tem o acesso correto a este projeto ou ele não foi adicionado como um dos colaboradores deste projeto. Desta vez, como o loop não pode contribuir diretamente para este projeto, o que vai fazer é, na verdade, criar uma bifurcação desse projeto. Então aqui você vê uma opção que diz ****, você pode adicionar o clique aqui. Vou clicar no menu suspenso. E você vê uma opção que diz Criar um novo garfo. Ei, a maneira como você seria levado a esta página, onde você será solicitado a dar um nome para o seu repositório. Você pode manter o mesmo nome do depositário original ou renomeá-lo para outra coisa. Por exemplo, talvez a aparência, aplicativo ou o que quer que seja, não importa. Opcionalmente, você também pode fornecer uma descrição e clicar nesse botão que diz criar bifurcação. Então, essencialmente, criamos um clone do projeto original na conta do Luke no GitHub. E Luke agora pode fazer tudo o que faria outra forma em seu próprio repositório público. E o fato de que isso é na verdade um clone ou uma versão bifurcada de algum outro repositório. Você verá que todo o histórico de commits é branches. Tudo está como está, exceto um repositório bifurcado. Você verá este ícone indicando que este é um repositório bifurcado. E também este texto que diz bifurcado do policial 1996 cortou meu limite público, que é o depósito original. Solute, agora pode começar a contribuir para este projeto. Ele pode até adicionar mais colaboradores. Se Luke está tendo uma equipe de desenvolvedores que podem querer contribuir para este projeto. Você pode adicionar colaboradores ou regras de proteção de filiais. Tudo o que se pode fazer com um repositório público. Você pode fazer o mesmo mesmo com o repositório bifurcado. Exceto, é claro, que você verá uma diferença do original depositado aqui. Essa referência será útil em um estágio posterior e falaremos sobre isso nas próximas palestras. Por enquanto. Vamos tentar clonar esse projeto. Vamos copiar o URL HTTPS. Parece que o computador simplesmente vai clonar seu próprio repositório. Clone com o Git e cole o URL. Deixe-me entrar nesse cd do diretório. E deixe-me digitar o comando git remote hyphen v significa detalhado. Como você pode ver, ele já adicionou um controle remoto com a origem do nome e está apontando para o repositório bifurcado. Então, quando digo origem, estou me referindo ao repositório bifurcado. E abaixo da linha também seria necessário adicionar outro controle remoto, que é remoto upstream. E isso aponta para que o repositório original continuará a partir do próximo. 96. 1303 Contribuir para as mudanças necessárias: Agora, quais são as mudanças que Luke quer contribuir para esse projeto? Vai trazer todas essas mudanças localmente, testá-las e, em seguida, enviar todas essas alterações para seu próprio repositório bifurcado, a fim de simular esse comportamento que fez vários commits. E, claro, como uma boa prática, vamos criar uma nova filial. E é aí que vamos fazer nossos compromissos. Isso é o que eu tenho pregado durante todo este curso. Nunca gostaríamos de fazer comércio estaticamente na filial principal, mas criaremos uma nova filial e faremos uma contribuição vazia. Então, vamos abrir isso com o código do Visual Studio bem rápido e criar uma nova ramificação. Vamos chamá-lo de recurso dez. Talvez. Crie uma nova ramificação. E eu vou simplesmente adicionar alguns arquivos. Um ponto TXT, por exemplo, vá para Controle de Código-fonte, criou um ponto TXT. Comprometa-se com as mudanças. E deixe-me comprometer mais um. Talvez dois pontos dx, dy, o que for. Só queria ter certeza de que veríamos alguns comentários. E esse ramo de recursos tem a palavra que apresenta nossas mudanças. Temos um ramo de destaque e fizemos alguns comentários nele. Você pode ver isso neste gráfico aqui, como você pode ver, o recurso que se ramifica, alguns comentários à frente. O ramo principal. Agora, e se, enquanto eu ainda estiver trabalhando nesse recurso, tivermos várias atualizações novas no repositório upstream ou no repositório original. Como vamos obter todas essas atualizações em nossa máquina local, bem como no repositório bifurcado. É sobre isso que vamos falar a seguir. 97. 1304 Sincronizar o repo Forked com o original e atualizar local: Ok, vamos ver como podemos manter nosso depósito local, bem como o repositório bifurcado em sincronia atualizados com o depositário original. Para simular o comportamento em que temos algumas novas atualizações no depósito original hoje. Deixe-me realmente ir para a conta do remetente. Quem é o proprietário desse repositório. E deixe-me fazer um commit no branch principal, talvez apenas adicionando um arquivo. Vamos dar um nome aleatório. Algo desse tipo. Ponto Apple TXT. Desculpe pelos nomes engraçados. Eu só queria manter as coisas simples. Vamos criar esse arquivo. Portanto, temos algumas mudanças novas na ramificação original. Agora, existem várias maneiras de manter nosso repositório bifurcado em sincronia com o repositório original. O que eu vou falar agora é a abordagem mais fácil de todas. Então, vamos agora para a conta do Luke no GitHub. Vamos atualizar a página. Portanto, esse é o repositório bifurcado. Aqui você vê uma mensagem que diz que esse ramo é um commit atrás do policial principal, que é o depositário original. E aqui você também vê uma opção para afundar o garfo. Se você clicar nele. Você verá a opção de atualizar o branch e observe que estamos atualmente no branch principal. Então, essencialmente, o ramo principal do repositório bifurcado é comparado com o ramo principal do depositário original. E é assim que o GitHub nos diz que, na verdade, somos um commit por trás do ramo principal do depositário original. Ao clicar na bifurcação de sincronização, você verá a opção de atualizar a ramificação, clique nela. Então, isso buscaria e mesclaria nossas mudanças. E como você pode ver, temos esse novo arquivo aqui. Agora, quando ele fez fetch e merge, é como uma operação de pool. E isso resultará em uma fusão rápida. E não há como termos conflitos aqui porque estamos seguindo boas práticas de não fazer nossas contribuições no ramo principal. Criamos um branch de recurso e é aí que estamos trazendo todas as mudanças não estavam tocando no branch principal. Então, quando pensamos em ambos os repositórios, não há como vermos qualquer tipo de conflito caso você não esteja seguindo boas práticas e faça comentários em seu branch principal, você pode muito bem estar vendo conflitos e então você tem que lidar com esses conflitos. Depois de tê-lo no repositório remoto, tudo o que você precisa fazer é extrair essas alterações até mesmo no seu repositório local. Vamos fazer isso bem rápido. E como você pode ver, obtivemos as atualizações do repositório padrão. 98. 1305 Sincronizar o repo Forked com original do repo local: Vamos dar uma olhada em uma outra maneira de manter o repositório bifurcado e o depositário local atualizados com o depositário original. Para isso, vamos rapidamente fazer mais um comentário. No depósito original, que fica na janela do ônibus. Só para simular o comportamento de ter novas atualizações no branch principal. Vou adicionar um novo arquivo, algo desse tipo. Mais uma vez, desculpe pelos nomes engraçados. Venha com o novo arquivo. Desta vez, o que vamos fazer é realmente puxar todas essas alterações para um repositório local e, em seguida, enviá-las para o nosso repositório bifurcado. Vamos ver como podemos fazer isso. Vamos fazer isso no Git Bash. Você também pode fazer o mesmo a partir do código do Visual Studio, se desejar. Em primeiro lugar, precisamos extrair as alterações do Depositário original. Como vamos fazer isso? Se eu disser git pull, isso realmente puxaria do remoto de origem, que é o repositório bifurcado. Mas, na verdade, queremos retirá-lo do depósito original. Como vamos fazer isso? Em primeiro lugar, precisamos adicionar esse controle remoto. Se eu disser git remote hyphen v, Você vê que temos rebaixamento de origem e está apontando para o repositório bifurcado. Vamos agora adicionar outro remote, git, remote add. E vou nomeá-lo como upstream. Como eu mencionei antes. Vamos chamar o depósito original de montante. E aqui vamos fornecer o URL do depositário original. Então, deixe-me copiar isso aqui. Eu também posso usar este link se eu quiser. Esse comando acabou de adicionar o repositório upstream. Se eu executar esse comando mais uma vez, você verá que agora temos algumas observações. Agora vamos tentar extrair as alterações do repositório upstream. Git pull e depois upstream main. Então, queremos manter nossa filial principal atualizada. Isso trouxe todas as mudanças. Esse é o arquivo que acabamos de criar. Você também pode ver isso no Visual Studio Code. No entanto, essas alterações ainda não estão disponíveis em nosso repositório bifurcado ou no servidor de origem. Então adivinhe o que precisamos fazer a seguir. Git push. E isso deve enviar esses novos commits para o repositório bifurcado. Se você acessar a conta de Luke agora e recarregar a página, verá essas atualizações. 99. 1306 Empurrando nossas mudanças para o repo forrado: Ok, vamos supor que Luke acabou com todas as mudanças do recurso dez. E agora ele está disposto a propor todas essas alterações ao remetente, que é o proprietário do depósito original ou do repositório upstream. Mas antes mesmo de Luke considerar fazer isso, ele precisa ter certeza de que ele tem todas as atualizações, todas as atualizações mais recentes do repositório upstream, e garante que seu repositório bifurcado, bem como o depositário local, estão atualizados com isso. Já vimos como isso pode ser feito nas últimas palestras. A segunda coisa que esse loop precisa ter certeza é realmente ler isso como ramificação de recurso na parte superior da ramificação principal. Então, vamos fazer isso bem rápido. Vou mudar para a ramificação do recurso dez. Vou clicar com o botão direito do mouse no commit mais recente do branch principal. E então eu vou escolher essa opção que diz o branch atual rebaseado nisso. Com isso, nos livramos possíveis conflitos que possam ocorrer. Se você se deparar com algum tipo de conflito, já sabia como lidar com isso. Depois de fazer isso, você realmente enviará todas essas alterações para o repositório remoto ou para o repositório bifurcado ou a origem. Então, vamos empurrar todas essas mudanças. Recebemos um aviso que diz que o recurso de ramificação Dan não tem ramificação remota. Você gostaria de publicar este branch? Eu digo, ok, eu quero escolher o modo ácido de origem. É para isso que eu quero publicar ou promover nossas mudanças . É um sucesso. Isso foi para a conta de Luke e veja se as coisas se refletiram. E com certeza, agora você está vendo, deixe-me recarregar a página. Agora você está vendo essa nova filial. Em seguida, veremos como podemos aumentar a solicitação pull para propor nossas alterações no cilindro mestre. Vejo você em seguida. 100. 1307 Como aumentar a solicitação de tração e mesclar as alterações no repositório upstream: Vamos ver como Luke pode propor essas mudanças para se render levantando um pull request. Há várias maneiras de fazer isso. Aqui você já vê uma opção para comparar e aumentar o pull request. Você pode clicar aqui ou escolher a ramificação do recurso na lista. Em seguida, clique no menu suspenso em contribuir e você verá a mesma opção para abrir um pull request. Como alternativa, você também pode ir para a seção pull requests e criar um novo pull request. Seja qual for a maneira que você seguir, você verá a tela onde precisamos comparar os ramos para ver a diferença dos dois. Aqui, vamos comparar a ramificação principal do repositório upstream com a ramificação de recurso do repositório bifurcado. O repositório aqui está se referindo ao repositório upstream. E aqui escolhemos o ramo principal. O repositório principal aqui está apontando para o repositório bifurcado. E aqui precisamos escolher o branch do recurso. Então isso vai mostrar um resumo de todas as mudanças que acabamos de introduzir na ramificação do recurso. Agora podemos ir em frente e criar a solicitação pull. O processo é muito semelhante ao processo de pull request que falamos anteriormente. Assim, uma vez que a pull request é levantada, eles podem realmente revisar as alterações. Ele pode aceitar ou negar ou pedir que você trabalhe em um monte de comentários, etc Vamos agora para o painel do Cinders. Recarregue o repositório principal. Aqui vai ver a solicitação pull. Vamos clicar nele. Já falamos sobre uma variedade de coisas que podemos fazer aqui. Por exemplo, posso dizer apenas descontos e mesclagem. Mas antes disso, como temos uma regra de previsão de ramificação, para fazer pelo menos uma revisão, vamos revisar rapidamente as mudanças e dizer que estou feliz com todas as mudanças. Vou aprovar e enviar a avaliação. Agora eu posso realmente ir em frente e escolher qualquer uma dessas opções. Talvez eu queira ir com o merge. Confirme a fusão. E agora todas essas alterações relacionadas ao recurso são mescladas na ramificação principal. Então você vê todos esses arquivos aqui, um ponto TXT e dois pontos TXT. E estamos dentro da filial principal. Durante todo esse processo, Luke nunca foi adicionado como colaborador no depósito original ou no repositório upstream. No entanto, ele foi capaz de contribuir para este projeto. Espero que faça sentido. Vejo você em seguida. 101. 1308 Explorando o projeto público existente: Neste vídeo, vamos explorar um dos projetos existentes disponíveis no GitHub e ver se podemos entender com base no que você aprendeu neste capítulo. Se você tem algum projeto em mente que você já conhece, então você pode pesquisá-lo aqui. Você pode explorar, explorar alguns dos projetos públicos. Você também pode dar uma olhada em projetos com base em um tópico específico. Aqui você verá uma lista de tópicos organizados em ordem alfabética. Aqui está uma lista de tópicos populares. Vamos clicar em talvez reagir. Vamos abrir aleatoriamente todos os projetos aqui. Um ponto x js. Eu vou simplesmente escolher algo aleatório. Talvez essa estrutura icônica. A primeira coisa que você notará ao visitar a página do projeto é o arquivo leia-me. arquivo Readme normalmente constituiria informações sobre o software, como você pode instalá-lo no caso de você querer começar como colaborador para este projeto, quais são todas as etapas envolvidas nisso? Para começar como colaborador, você encontrará projetos que são plantas e um monte dessas informações no arquivo ReadMe. Então esse é provavelmente o ponto de partida. Se você quiser começar com um projeto específico. Depois de ler o arquivo ReadMe, você pode realmente começar com a contribuição. Mas vamos explorar a seção Pull Request aqui. Como você pode ver atualmente, tem cerca de 33 pedidos ruins de atores que ainda não foram mesclados, são revisados. Basicamente, você verá alguns tipos de solicitações. A primeira é aquela que falamos em nossas palestras anteriores. O segundo é algo que ainda não conversamos. É chamado de solicitações pull de rascunho. Você pode dizer que um pull request específico é um rascunho para solicitação. Ao olhar para este ícone, se ele estiver esmaecido, será um rascunho de pull requests. Você pode estar se perguntando o que é um rascunho para solicitações. Vamos falar sobre isso nas próximas palestras. Mas, basicamente, se você tiver alguma alteração que apenas proposta para ter a discussão ou receber feedback, mas não se destina a ser mesclada. Em seguida, você pode criar um rascunho para solicitações. Basta iniciar essa discussão. Todo mundo pode realmente dar uma olhada nas alterações do seu código e colocar alguns comentários sobre isso. E com base nisso, você decidirá se deseja continuar com isso ou não. Você também percebe esses chamados rótulos à direita de cada título de pull requests. Novamente, isso é algo que abordaremos nas próximas palestras. Mas os rótulos permitiriam essencialmente que você classificasse as solicitações da pesquisa. Em outras palavras, isso ajudaria você a categorizar os pedidos ruins. Por exemplo, se eu clicar nesse rótulo, você verá todos os pull requests que correspondem a esse rótulo específico. Como proprietário do repositório, se eu quiser dar uma olhada na lista de pull requests que corresponde a um rótulo específico. Eu posso fazer isso. Você pode estar vendo um monte de outras coisas aqui sobre as quais ainda não falamos. Podemos explorá-los nas próximas palestras. Mas acho que você chegou a um estágio em que pode aprender as coisas por conta própria. Na verdade, esse é o objetivo deste curso para fazer você se posicionar sozinho. Eu realmente não posso ensinar tudo o que está lá fora. Meu trabalho é fazer com que você se sinta confortável com a tecnologia. E acho que até agora chegamos a esse estágio. Agora cabe a você ter que explorar, ir além e fazer algo para expandir ainda mais essas habilidades. Uma das melhores maneiras de fazer isso é basicamente contribuir com um desses projetos. Por exemplo, se você está aprendendo React ou Python ou qualquer outra coisa, basta dar uma olhada em vários projetos que estão aqui relacionados a esse tópico específico e começar a contribuir. Todo projeto deve ter algumas instruções sobre como você começar como colaborador. Você pode passar por isso e começar com a contribuição. Então, esses são todos os pull requests levantados por pessoas como você e eu. E você pode ver que esse projeto foi bifurcado por mais de 13 mil vezes. Até o momento desta gravação. Vamos dar uma olhada na lista de problemas. Portanto, existem cerca de 554 problemas atualmente. Se você quiser relatar um bug ou sugerir um novo recurso, você também pode fazer isso clicando em novo problema. Você pode adicionar o relatório, um bug ou solicitar um recurso. Você pode ler a documentação, etc. Na verdade, esse layout é personalizado para este projeto. Você pode ver um layout um pouco diferente dependendo do projeto que está visualizando. Por exemplo, digamos que eu usei software deles e encontrei um bug, e então eu queria relatar esse bug. Então, eu certamente posso clicar nisso. E eles criaram um formato para relatar o bug. Em primeiro lugar, eles queriam ter certeza de que eu lia as diretrizes de contribuição. Depois de fazer isso, posso clicar nesta caixa de seleção, seu código de conduta, etc. o Washington, qual bug está decidindo? Qual é o comportamento atual, qual é o comportamento esperado? Etapas claras para reproduzir e um monte de outras informações para ajudar alguém que queria corrigir esse bug a obter todas as informações necessárias para corrigir o bug. Vamos voltar aos problemas. Então, você pode dar uma olhada nesses problemas. Se você acha que pode consertar um desses, já sabe o que fazer. Você só precisa bifurcar o projeto, clonar o projeto, sua máquina local, corrigir o bug, enviar essas alterações para o repositório bifurcado e, em seguida, aumentar os pull requests. Como eu disse antes, tome isso como uma tarefa e realmente contribua para um projeto estranho, eles são valiosos no GitHub. Depois que você tiver suas pull requests mescladas ou aprovadas pelos proprietários do código, isso lhe dará muita satisfação e uma sensação de realização. Depois de ver isso acontecendo. Pode levar algum tempo para que todo o processo seja concluído. Mas eu recomendo que você faça isso. E dessa forma você está juntando tudo. O que você aprendeu neste curso até agora. No restante do curso, falaremos sobre todas as peças que faltam nessas tecnologias. Mas, como eu disse antes, acho que chegamos a um estágio em que você está sozinho e aprendeu todos os tópicos essenciais do Git e do GitHub. Desejo-lhe boa sorte, mas ainda não terminamos o curso. Também temos muitos outros tópicos para discutir. Então, sim, assuma isso como uma tarefa e contribua para projetos valiosos fora do dia. Vejo você em seguida. 102. 1401 Estratégia de Branqueamento explicada: Vamos falar sobre a estratégia de ramificação. Temos o principal ou o ramo principal. E, de um modo geral, tudo o que vai dentro do mestre ou do ramo principal deve estar pronto para produção. Em outras palavras, você precisa presumir que a água entra no mestre ou a filial principal é algo que seu cliente começará a usar. Na verdade, você também pode ter algum tipo de automação em vigor, na qual ele constantemente seleciona o código do mestre ou do branch principal, cria um artefato e os implanta a inscrição na produção para que seus clientes recebam agora todas essas novas atualizações ou recursos. Como exemplo, imagine que você está desenvolvendo um sistema operacional como o Windows. No momento de entregar algo na filial principal ou principal, seus clientes podem ver um pop-up dizendo que há um novo service pack disponível para instalação. Em seguida, eles instalarão esse service pack para obter todos os recursos ou correções de bugs mais recentes. O fato de ser um código pronto para produção significa que você deve ter cuidado com o que vai dentro do branch principal ou principal. O que vai dentro do branch principal ou principal deve ser totalmente testado. Código de qualidade garantida que você realmente não pode arriscar ter qualquer tipo de bug. Então, obviamente, por essas razões, ele não pode disponibilizar o branch master ou o branch principal para que os desenvolvedores contribuam com seu código. Se você fizer isso, toda vez que alguém mesclar o código no branch principal para cada recurso, seus clientes também receberão essas atualizações, que obviamente não são tão testadas. E, obviamente, não é uma boa prática. Então, o que vamos ter é que vamos ter outro ramo chamado ramo de desenvolvimento. E esse será o ramo mais ativo para o qual todos os desenvolvedores contribuirão. Na verdade, no momento em que criarmos um repositório GitHub, vamos criar o branch de desenvolvimento como o branch padrão para que sempre que alguém clone o código em sua máquina local, veremos o branch de desenvolvimento como um branch padrão. Na verdade, não vamos permitir que ninguém contribua para o ramo principal ou para o ramo principal. Em vez disso, abriríamos apenas o ramo de desenvolvimento ou a contribuição. Somente um conjunto específico de pessoas terá as permissões no branch principal ou principal para realmente mesclar o código testado de qualidade. E mesmo em desenvolvimento, toda vez que alguém entrega um código, gera um pull request. Também podemos ter algum tipo de automação aqui para verificar a qualidade do código. Por exemplo, verificar se há alguma vulnerabilidade de segurança, está tentando executar alguma verificação, verificar se há erros programáticos, etc. para garantir que o código ainda em conformidade aos padrões de qualidade da organização sempre que alguém contribui para esse ramo. Agora imagine que há vários recursos fornecidos no ramo de desenvolvimento. E foi nesse momento que percebemos que podemos realmente liberar todo esse feto para o usuário final. Agora, podemos realmente mesclar todas essas alterações com todos os recursos mais recentes no branch master. Assim como seus clientes começarão a usar. Mas temos mais um passo para cuidar. Na verdade, teremos outra ramificação chamada branch release. E é isso que vamos mesclar todos os desenvolvimentos mais recentes do ramo de desenvolvimento. A ramificação de lançamento fica entre a ramificação principal principal e a ramificação de desenvolvimento. É como uma inscrição de pré-produção que podemos realmente fazer alguns testes de automação para garantir que todos os recursos estejam funcionando conforme o esperado. Uma vez que o teste é feito, tudo é chamado de garantido. Em seguida, mesclaremos todas as alterações da ramificação Release para a ramificação principal real. E o código agora se tornaria a versão oficial do software que os clientes usarão. Bem, tenho certeza de que tudo isso pode parecer confuso. Então, deixe-me dar um exemplo em tempo real e orientá-lo por esse diagrama mais uma vez. Então eu entendo melhor e faremos isso a seguir. 103. Estratégia de ramificação 1402 com cenário em tempo real: Ok, vamos entender tudo isso com um exemplo rápido em tempo real. Então imagine que temos vários desenvolvedores que contribuíram com seu código, um monte de recursos para o ramo de desenvolvimento. Ou pode ser o caso seu projeto ter sido bifurcado por várias pessoas. E eles levantaram pull requests que eventualmente foram mesclados no ramo de desenvolvimento. Mas, em última análise, temos vários recursos em um ramo de desenvolvimento. E é nesse momento que percebemos que podemos realmente entregar isso ao cliente como uma nova versão. Agora podemos simplesmente mesclar todas essas mudanças de som com a ramificação de lançamento. Mas antes disso, vamos criar mais uma ramificação, a versão com um ponto ou em tudo, com a suposição de que esta é a primeira versão do software que estamos lançando. O tipo de formato que estamos seguindo para piorar o software é o chamado versionamento semântico. Vamos falar sobre isso nas próximas palestras. Mas, por enquanto, essa é a versão. E vamos nomear nossa filial com esse número de versão. Você sabe, o propósito de criar esse ramo daqui a pouco. Então, uma vez que criamos uma ramificação chamada porção um ponto o ponto o da ramificação de desenvolvimento. Em seguida, mesclaremos todas essas alterações no branch de lançamento. E é aqui que todos os testes acontecem e qualquer coisa adicional que você queira fazer, você pode fazer isso aqui antes de realmente mesclar essas alterações no branch master, que deve ser código pronto para produção. Então, eventualmente, ele acaba no ramo principal ou no ramo principal também. O bom dessa estratégia é que, enquanto você está ocupado lançando o software e testando o software completamente, antes de realmente colocá-los na produção, Rome e outros desenvolvedores podem. na verdade, continue trabalhando nessa tarefa e dilua os recursos no ramo de desenvolvimento. Agora imagine que o cliente tenha relatado um bug. Talvez um software permitisse que o cliente relatasse um bug no momento em que o definisse. Então, suponha que o cliente de visão de mundo encontrou o bug, ele relatou. E você percebe que é realmente um bug muito sério que precisa ser corrigido com prioridade. Então, o que você precisa fazer é criar uma ramificação dessa versão. E você vai incrementar o valor em um. Novamente, isso é chamado de versionamento semântico. Vamos falar sobre isso. Mas, essencialmente, você criará uma ramificação a partir da versão anterior. E é aqui que você vai consertar o bug. Depois de corrigir o bug, você testará todas as mudanças. E então você vai mesclar todas essas mudanças na ramificação de desenvolvimento, bem como na ramificação de lançamento e eventualmente, na ramificação principal ou principal também. Então, seu cliente terá a correção para o relatório de bug que eu realmente demonstrarei tudo isso no GitHub em breve, para que você tenha uma melhor clareza sobre o que exatamente está acontecendo aqui. Vejo você em seguida. 104. 1403 Versões semânticas explicadas: Vamos falar sobre controle de versão semântica. controle de versão semântico é uma prática padrão seguida para adoração em uma determinada versão de software, biblioteca ou API. E aqui está o formato do versionamento semântico. A primeira parte é a versão principal. A segunda parte é a versão secundária e a terceira parte é chamada de patch. A forma como o versionamento semântico funciona em K, software. O software é um pouco diferente em comparação com a forma como funciona no caso de uma API. Vamos primeiro falar sobre o caso de um software, algo como um editor de vídeo ou um sistema operacional, etc. Portanto, sempre que você tiver alguma mudança significativa haverá uma grande quantidade de recursos. Ou talvez você tenha excluído alguns dos recursos existentes são significativamente modificados, recursos existentes, então você pode querer considerar incrementar a versão principal. Quando você fizer isso, você redefinirá os valores tanto do menor quanto do patch de volta para 0. Ou, se você tiver apenas alguns recursos entregues e eles não forem muito significativos, considere aumentar o número da versão secundária. E se você tiver alguma correção de bug ou hotfixes sobre esta versão, então você pode considerar incrementar a versão do patch à medida que introduzir novos hotfixes, você continuará incrementando o número do patch assim. Agora, digamos que você trabalhou em mais alguns recursos e eles são apenas pequenas mudanças. Você pode incrementar novamente o número da versão secundária, mas então você tem que redefinir o valor do patch de volta para 0. É assim que o versionamento semântico funciona. E, como mencionei antes, a maneira como isso funciona no caso de uma API, é um pouco diferente de uma API, sempre que você incrementa o valor da versão principal, significaria que você introduziu mudanças significativas que não seriam mais compatíveis com versões anteriores. Por exemplo, talvez você tenha removido certos recursos ou modificado significativamente alguns dos recursos existentes. O que isso significa é que todos os projetos que estamos usando versão anterior da sua biblioteca teriam que considerar alterar o código antes que eles pudessem usar a versão mais recente da sua biblioteca. Isso é o que significa quando você incrementa a versão principal. No entanto, incrementar a versão secundária significaria que os novos recursos ou funcionalidades foram adicionados e não exige que ninguém modifique o código para tornar o código compatível com sua biblioteca. Os patches são semelhantes ao patch que falamos anteriormente. Se estivermos incrementando, isso significa que você forneceu uma correção de bug ou um hot fix. É assim que o versionamento semântico funciona. Vejo você em seguida. 105. 1404 Entendendo as tags do Git: Vamos falar sobre tags e obter. Etag é simplesmente uma diferença que aponta para um ponto específico da boa história. Em outras palavras, o ataque simplesmente apontaria para um commit específico. Agora isso pode soar como um galho. Mesmo branch aponta para um commit específico, e até mesmo tag aponta para um combate específico. Mas a diferença entre os dois é que o branch seria atualizado toda vez que fizéssemos um novo commit no branch. E o branch apontaria para o commit mais recente, enquanto a tag permaneceria constante. Se criarmos uma tag apontando para um commit específico, ela permanecerá assim para sempre, a menos que façamos algo com essa tag explicitamente. Agora, qual é a vantagem de criar uma tag? Por que queremos criar uma referência a um commit específico e mantê-la constante? Vamos dar uma olhada. Então, isso é do nosso exemplo anterior, 1 segundo, suponha que lançamos um novo software e eventualmente, temos mudanças no branch master. É neste momento que vamos criar uma tag, dando a ela o número da versão do software que tem seu nome. Como assumimos que esta é primeira versão do software, vamos piorá-la como um ponto o ponto o. E essa tag aponta para esse commit em particular, o master ou o branch principal. Agora, suponha que fornecemos um hot fix. E mais uma vez, entregamos isso fixo no branch master. Vamos criar outra tag, dando-lhe um número de movimento. Então, como isso é uma correção de bug ou um hot fix, nós apenas incrementamos o número do patch em um. Então, essencialmente, estamos seguindo o versionamento semântico aqui e essa tag aponta ou temos a referência do commit no branch master com essa correção. Mas qual é o sentido de ter todas essas tags? Bem, um outro caso de uso é, digamos que eu queria criar um artefato baseado em uma versão específica. Então talvez eu possa executar um comando dizendo que eu quero criar um artefato para a versão um ponto o ponto o. Posso executar o comando especificando essa tag. E a ferramenta criaria o artefato para mim, que pode ser implantado na inscrição de produção, etc. Ou talvez eu possa colocá-lo nas notas de versão para os clientes baixarem e usarem. Não podemos usar branch nesse caso porque branch seria atualizado de vez em quando. No momento em que fazemos um novo commit no branch, tags seriam úteis em tal situação. Em seguida, vamos dar uma olhada em tudo isso em ação para que você tenha visão completa do que exatamente está acontecendo e como isso vai funcionar. Vejo você em seguida. 106. 1405 Braching Workflow em ação: Ok, agora vamos ver tudo em ação e espero que você esteja pronto para isso. Vamos primeiro seguir em frente e criar um novo repositório. Vamos chamá-lo de talvez super áudio. Talvez estejamos criando uma ferramenta de edição de áudio. E talvez eu queira adicionar o arquivo leia-me também. Se desejar, você pode realmente ir para as configurações e alterar o nome do branch padrão do main para outra coisa, se desejar. Talvez possamos mudar isso para mestre. Não é obrigatório. Mas eu estou fazendo isso de qualquer maneira. Vou criar o repositório. Como você pode ver, temos o branch master. E esta será a chave de produção, o que significa que o que quer que vá dentro do ramo mestre entraria na matrícula de produção. Em seguida, vamos em frente e criar as outras duas ramificações. Um deles será o ramo de pré-produção e inseriremos o nome dele como lançamento. E outro ramo é para desenvolvimento. Vamos chamá-lo de desenvolver. Essa ramificação teria o código mais recente de todos os colaboradores que colaboram conosco. Vamos agora para as configurações e tornar a ramificação de desenvolvimento como uma ramificação padrão. Só para que, se alguém clonar o projeto, eles vejam a ramificação de desenvolvimento como padrão, na qual podem contribuir. Então, vamos mudar essa ramificação de mestre para desenvolver e clicar em Atualizar. Agora, se eu voltar, você já verá o ramo de oliveira escolhido porque esse será o ramo padrão agora. Agora, para simular o comportamento, ter vários recursos no ramo de desenvolvimento. Vou simplesmente adicionar alguns arquivos. Mas você precisa fazer uma suposição que talvez tenhamos feito algumas mudanças relacionadas a recursos e contribuído para essa ramificação. Pode ser o caso de outra pessoa para o projeto e levantar pull requests nesse branch específico. Então, quem quer que seja esse projeto, é esperado, a corrida puxa pedidos na agência do dólar. Eles não têm nenhum tipo de permissão ou não esperamos que ninguém faça contribuições para o branch release, hard o branch principal ou o branch master. Então, vamos em frente e criar alguns arquivos. Crie um novo arquivo, vamos chamá-lo de recurso TXT de um ponto. Só para manter as coisas simples, vamos criar mais um arquivo. Crie um novo recurso de arquivo para pontilhar TXT, por exemplo, e confirme o código. Então, temos um monte de commits aqui. O primeiro foi o arquivo leia-me, e os outros dois são para os recursos. Agora, qual é a próxima coisa a fazer? Você pode fazer um palpite? Supondo que quiséssemos lançar nosso software ou a primeira versão do nosso software para o usuário final. Bem, vamos primeiro criar mais um ramo. E vamos nomear essa ramificação com versionamento semântico. Como esta é uma versão muito falsa do software que estamos lançando, vamos nomeá-lo como um ponto o ponto o. Então, vamos criar esse ramo a partir do ramo de desenvolvimento. Enquanto isso, outros desenvolvedores podem continuar contribuindo para a agência do dólar. Mas o que vamos fazer a seguir é que precisamos mesclar todas essas alterações no branch de lançamento desse branch específico que acabamos de criar. Então, adivinhe o que precisamos fazer a seguir. Maneira de aumentar solicitações pull. Atualmente, o branch de lançamento não tem esse recurso levando a alterações quando obtê-los aqui. Vou para pull requests, criar um novo pull request. Aqui vou escolher o branch de lançamento e quero compará-lo com o branch da versão, vamos chamá-lo. Então, aqui estão todos os recursos que levam a mudanças. E eu vou criar o pull request. Supondo que tenhamos feito todas as formalidades de revisão, digitalização do quadro e tudo mais, vamos em frente e mesclar todas essas mudanças. Ainda não queremos excluir essa ramificação porque ela será útil posteriormente. Então, se você voltar para o repositório e for para o branch de lançamento, agora você terá todas essas alterações relacionadas aos recursos. Portanto, podemos estar executando alguns testes automatizados e assumindo que tudo está funcionando conforme o esperado, agora decidimos enviar todas essas mudanças em nosso módulo, essas mudanças no branch master então que nossos clientes começarão a usar nosso software. Então, mais uma vez, vamos levantar outro Pull Request. Novo pull request. Aqui eu vou escolher o branch master. E aqui vou escolher o branch de lançamento. E vamos seguir em frente e criar a solicitação pull. Vamos também mesclar todas essas alterações no branch master. Talvez com três bits e mesclar. Também podemos fazer o commit do Squash para combinar todos os commits em um único commit. Mas acho que estamos bem com isso. Então, agora lançamos oficialmente nosso software para o usuário final. Então, se eu clicar em Mestre, você verá o recurso levar a mudanças aqui. Idealmente, devemos criar uma tag bem aqui. Mas vamos falar sobre tags nas próximas palestras. Vejo você em seguida. 107. 1406 Fluxo de trabalho Hot Fix em ação: Ok, vamos continuar. Agora, suponha que seu cliente relatou um bug e você percebe que ele é realmente um bug crítico que precisa ser corrigido com prioridade. E então você não está planejando ter um hot fix. Então, qual é a primeira coisa que precisamos fazer? Bem, já temos uma filial à mão. Aquele que criamos anteriormente com o nome da versão. É aqui que isso é útil. Podemos criar outro branch a partir desse branch para corrigir o bug. E então vamos mesclar todas essas mudanças no branch de desenvolvimento bem como no lançamento e eventualmente, no branch master também. Assim, os clientes receberiam uma atualização com a correção. Então, eu escolhi essa versão específica do branch. Vamos agora criar outro branch para corrigir o bug e obter a versão que precisamos fornecer aqui. Já que você está andando no hot fix foi incrementar o valor da versão do patch em um. Desta vez, o nome da filial será 101. Eu vou criar esse ramo. Mais uma vez para simular o comportamento de corrigir um bug. Deixe-me simplesmente criar um bug de arquivo, ponto fixo dxdy, tanto faz. E eu vou cometer essa mudança. Agora precisamos mesclar essas mudanças no ramo de desenvolvimento. Nós podemos fazer isso daqui. Podemos ir para puxar a seção transversal e levantar um novo pull request. Escolha a ramificação que acabamos de criar e vamos compará-la com a ramificação de desenvolvimento. Então, nós temos isso consertado aqui. Crie uma classe de produto e deixe-nos sair. Então vá em frente e mescle a correção do bug na ramificação de desenvolvimento. E com certeza, se você voltar ao ramo de desenvolvimento, verá a correção do bug. seguiremos etapas semelhantes para o lançamento. Fomos fazer um pull request. Vamos escolher o lançamento aqui. E o branch de correção de bugs limpou os pull requests. E isso vai em frente e mescla essas mudanças. Agora, depois de muitos testes, as coisas humanas estão funcionando muito bem. Vamos seguir em frente e mesclar as alterações do branch Release para o branch master. Como você pode ver, agora temos a correção do bug na ramificação de lançamento. Vamos criar um pull request bem rápido. Vamos comparar a ramificação de lançamento. Me desculpe. Vamos comparar o branch master e o branch release e mesclar todas essas alterações no branch master. Para voltar e mudar para o branch master deve ser capaz de ver a correção do bug e é assim que você entrega um patch. Em seguida, falaremos sobre como podemos criar tags. E, de fato, perdemos a criação da tag na versão anterior do nosso software. Mas também podemos criar tags para os commits que já foram feitos. Como fazemos isso, há algo sobre o qual falaremos a seguir. Vejo você em seguida. 108. 1407 Criando tags Annotated vs tags leves Tags de rubor para o controle remoto: Ok, vamos ver como podemos criar tags. Podemos adicionar as tags create no GitHub, ou podemos fazer isso a partir da linha de comando do nosso Git local também. Vamos ver os dois caminhos. Primeiro, vamos explorar como podemos fazer isso localmente a partir do Git Bash. A propósito, para economizar tempo, eu já adicionei o Sr. Luke como um dos colaboradores deste projeto. E aqui está o relato de Luke. A primeira coisa que Luke vai fazer é clonar esse projeto em sua máquina local. Então, suponha que este seja o computador de Luke. Vou lançar o Git Bash aqui. E vamos clonar rapidamente o projeto. Clone Git. Vou colar o URI. Então, vamos entrar nesse projeto. Limpe a tela. Então, vamos criar tags. Podemos adicionar a criação de uma tag leve ou anotada. Então, basicamente, existem dois tipos de tags que podemos criar. Quando se trata de tag leve, é apenas um nome ou um identificador e designado para um commit específico. Considerando que quando se trata de tag anotada, além de um nome e um apontado para acomodar. Ele também terá alguns metadados, como o nome do marcador, endereço de e-mail, data, etc. Se você quiser armazenar todos os metadados junto com a etiqueta, é melhor criar uma etiqueta anotada e não um tanque leve. E na maioria dos casos, é sempre relevante criar uma etiqueta anotada ou um tanque leve. Por razões óbvias. Saberemos quem o criou quando eles o criaram. E até saberíamos o endereço de e-mail da pessoa que criou esse tanque. Então, vamos primeiro ver como podemos criar tags anotadas. Basicamente, não criamos tag para a primeira versão do nosso aplicativo. Então, vamos primeiro dominar o ramo. Se eu fizer git branch, iPhone, não. Você vê que todas essas ramificações são ramificações de rastreamento remoto, mas não temos uma ramificação local para a ramificação mestre. Então, para conseguir isso, vamos fazer git checkout ou uma boa mudança para o branch master. Agora vamos dar uma olhada na lista de commits que estão no branch master. Então, essencialmente, é aqui que deveríamos criar uma tag que represente a primeira versão do nosso aplicativo. Então, isso foi logo antes do hot fix que demos. Então, como vamos criar uma tag para um dos comentários anteriores? Vamos dar uma olhada. Portanto, o comando para criar a tag é git tag, hífen uma tag com quatro anotações. E vamos especificar um identificador exclusivo ou um nome para essa tag. E na prática padrão, queremos dar a versão semântica do nosso lançamento. Então, tudo isso vai ser a primeira versão do nosso aplicativo. E agora especificaríamos o HashCode da tocha. Queremos que essa tag aponte para. É como se tivéssemos voltado no tempo e criado uma tag. Neste commit em particular. Vou colar esse código hash. Além disso, também forneceremos uma mensagem significativa descrevendo do que se trata essa tag. Alguma descrição sobre isso parecia ter estragado tudo. Vamos redigitar o comando. Etiqueta Git. Hífen a. Wee one.org.au especificou o hífen do HashCode m. Descrição da soma. Se você não fornecer a mensagem com a opção hífen m, você verá um editor de texto padrão sendo aberto para você inserir alguma mensagem. No entanto, se você fornecer essa opção, nota etc., será aberta. Então isso deve criar uma tag para nós. Se você executar o comando git tag, você verá toda a lista de tags que estão disponíveis. Então, se alguém clonar o projeto, eles também verão todas essas tags. Agora vamos em frente e criar uma etiqueta leve. E o comando para isso é bem direto. Obtenha uma tag e um identificador ou um nome para essa tag. Então, desta vez eu vou dizer que nós um ponto, ponto um. Porque, por padrão, quando você tenta criar uma tag, ela apontaria para o mesmo commit para o qual o head está apontando. Então, atualmente, isso apontava para o último commit off master branch. E então essa tag, que é uma tag leve, porque não fornecemos a opção de hifenização, também apontará para o commit desk off master branch, que inclui a correção do bug. E se você se lembra de acordo com o versionamento semântico, aumentamos o valor da versão do patch em um. Vamos apertar Enter. E acabamos de criar mais uma tag. Uma é a tag anotada e a outra é a tag leve, que não tem nenhum tipo de metadados. Agora, como publicamos todas essas tags no repositório remoto? Bem, vamos simplesmente usar o comando push padrão. Mas temos que especificar explicitamente que também queremos enviar tags. Por padrão, o comando push não enviará as tags. Então, vou informá-lo explicitamente. Então, vamos dizer que git push origin é o controle remoto para onde queremos empurrar todo esse imposto também. Podemos especificar qual tag queremos enviar especificando seu nome, o identificador, assim como são. Também podemos dizer tags para enviar todas as tags para o repositório remoto. Como Luke já tem permissão para esse repositório, conseguimos enviar todas essas tags para este depósito. E você pode vê-los aqui. Se você clicar nessas tags, verá que temos esses dois tanques que continuarão a seguir. 109. 1408 Compreender como as tags são armazenadas Estado principal destacado com tags: Anteriormente, criamos algumas tags. Uma é uma etiqueta anotada, a outra é um tanque leve. Vamos ver como eles são realmente armazenados no. Se você for para a pasta refs, agora você verá essa pasta com as tags de nome. E é aí que você verá essas duas tags. Mas eles anotam que a tag é realmente armazenada como um objeto. Enquanto o tanque leve é semelhante a um galho, não é um objeto. Então, vamos abrir o Washington 101. E está apontando para um comentário específico. Vamos tentar imprimir esse objeto com esse HashCode. Arquivo git cat. Em primeiro lugar, vamos dar uma olhada no tipo desse objeto. Como você pode ver, ele está apontando para o objeto cometa. Se você for bonito imprimir esse objeto, você verá os detalhes sobre esse commit. Mas agora vamos abrir o arquivo, que era uma tag anotada e ver para o que ele aponta. Deixe-me copiar esse código hash, voltar ao Git Bash e tentar imprimir o tipo do objeto. Desta vez, isso vai ser do tipo tag. E se você der uma olhada no conteúdo desse objeto tag, você verá o commit para o qual ele aponta. E também há alguns metadados junto com ele. Como o identificador da tag, quem a criou e algumas descrições sobre a tag também. Também podemos visualizar o estado do repositório em uma tag específica usando o comando git checkout. Então, deixe-me fazer git tag para dar uma olhada na lista de tags disponíveis. E vou usar o comando git checkout, especificando o nome da tag. Talvez eu queira levar meu repositório até essa data. E como você pode ver, estamos no estado principal desapegado. Já falamos sobre isso em um de nossos capítulos anteriores. Mas se você voltar para o diretório de trabalho, não verá esse hot fix. Porque no momento da criação dessa tag, não temos essa correção. Espero que faça sentido. Vejo você em seguida. 110. Lançamentos e criação de tags no GitHub: Tudo bem, vamos falar sobre lançamentos. De acordo com o que o GitHub tem a dizer sobre lasers. Aqui está o que diz. Você pode criar uma versão para pacote de software junto com as notas de versão e links para arquivos binários para outras pessoas usarem. Nesta chamada, você fornecerá alguma documentação técnica sobre o seu lançamento. Então, você gostaria de listar todas as mudanças que fazem parte da nova versão. As etapas de instalação, os binários são executáveis, etc. Você colocaria todas essas informações como parte das notas de versão para ajudar seus clientes ou usuários finais a entender tudo sobre a nova versão que eles precisam saber. Então, vamos em frente e tentar criar uma nova versão no GitHub. E, a propósito, sua organização pode estar usando alguma outra ferramenta para documentar o lançamento. Se você não tiver essa ferramenta, podemos usar o GitHub para o mesmo. Podemos associar uma tag para uma versão específica. Podemos escolher um dos existentes, por exemplo. Ou podemos ir em frente e criar uma nova tag. E é assim que você vai criar uma nova tag no GitHub. Por exemplo, talvez você possa dizer que nós um ponto 0 ponto dois, ou qualquer outra coisa. No momento, não temos novas mudanças. Não faz sentido aumentarmos a versão do nosso software. Em vez disso, vamos usar apenas uma das tags existentes. Assim. Vamos dar um nome a ele. Solte V, um ponto o ponto o, por exemplo. Aqui. Sua bicicleta leva algum tempo para documentar tudo sobre o lançamento. Então, talvez você liste todos os problemas que foram abordados, todos os novos recursos que foram introduzidos. Se houver algum recurso obsoleto, você também gostaria de listá-los. Talvez algumas etapas de instalação, para download, executável, etc. Você colocaria tudo o que deseja que seu usuário final veja e entenda sobre o lançamento. E assim que terminar com isso, você iria em frente e publicaria o lançamento. E é assim que parece. Obviamente, não preenchemos isso o suficiente para realmente ver algo significativo. Mas isso foi lançado para você. Os clientes podem passar por toda a descrição sobre o lançamento. E o baixo da guitarra carregou automaticamente o código-fonte. Alguém poderia fazer o download se quisesse. Então é só isso. Vejo você em seguida. 111. 1501 Dismiss as aprovações de pedido de puxar para novos commits: Ok, vamos falar sobre essa regra de previsão de ramificação que diz dispensar a cauda, aprovações de pull request, novos commits são enviados. O que isso significa é que sempre que alguém levanta um pull request e também assume que até mesmo a revisão está concluída, mas essa pull request, agora antes de mesclar essas alterações em algum outro branch, levou a uma equipe de dólar por quilômetro ou mudanças na filial que queremos fundir. Agora, se permitirmos que as mudanças sejam revisadas mais uma vez, não somos sua ala. Esta opção está dizendo que, se habilitarmos essa opção, significa que queremos exigir o processo de revisão, mais uma vez, revisando todas as alterações mais recentes antes que elas possam ser mescladas em outra ramo. Desative essa opção e observe o abuso necessário para mesclar as alterações. Se você entendeu o que acabei dizer, isso é muito bom. Você pode pular o próximo vídeo. Caso contrário, apenas espere. Vou demonstrar o mesmo. Então, no momento, isso está desativado. Deixe-me voltar ao depósito e levantar rapidamente uma solicitação pull para isso. Deixe-me criar outro branch com algum nome aleatório é df. E vamos também ter um commit. Talvez adicionando um novo arquivo. Vamos dar um nome, algo desse tipo, e confirmar as mudanças. Vamos levantar a solicitação pull. Vamos comparar o branch principal com o branch que acabamos de criar. Crie pull request. Crie pull request. Então, isso criou os pull requests. Precisamos de pelo menos uma revisão aprovada antes de mesclar essas alterações. Agora, a mesma pessoa que realmente criou um pull request não pode revisar seu próprio código. Para isso. Eu já adicionei o Sr. Luke como um dos colaboradores deste projeto. Avise-me, acesse a conta de Luke e aceite rapidamente as alterações. Então, aqui está a solicitação pull da conta do Luke. E vou adicionar minha avaliação vou revisar essas mudanças, aprovando tudo. Agora, se você voltar a somar esses segundos, verá que as alterações foram aprovadas e que posso ir em frente e mesclar a pull request. Enquanto isso, antes de mesclar as alterações, deixe-me tentar fazer outro commit no novo branch que acabamos de criar. Vou voltar à base de código e àquela ramificação. E deixe-me adicionar outro arquivo com algum outro nome aleatório, assim e confirmar as alterações. Se voltarmos às solicitações pull, agora você também verá essas novas mudanças. No momento, você pode ver que nenhuma revisão adicional é necessária para mesclar as pull requests. Isso porque essa opção aqui está desativada. Deixe-me ativar essa opção. Salvar alterações. Deixe-me digitar rapidamente a senha. E agora, se eu fizesse outra mudança e me comprometesse com esse ramo, deixe-me fazer isso bem rápido. Algo desse tipo. Comprometa-se com as mudanças. Se eu voltar aos pull requests, desta vez, você verá que precisamos de pelo menos uma revisão mais uma vez antes de podermos mesclar essas alterações. Bem, como o domingo é o proprietário deste repositório, é capaz de ver essa opção para realmente mesclar sem esperar os comentários sejam atendidos ou sem que a visualização seja feita. Mas, idealmente, as lapelas não poderão ver essa opção. Mas espero que você tenha entendido essa regra de proteção de ramo. Vejo você a seguir. 112. 1502 Configurando proprietários de código com padrões: Vamos falar sobre essa regra de proteção de ramificação que diria que é uma revisão obrigatória dos proprietários do código. Basicamente, o github nos permite criar um arquivo especial com os proprietários do código de nome, onde podemos especificar quem possui o quê com base nos padrões de arquivo. É um pouco semelhante aos padrões que estamos especificando um arquivo dot gitignore. Mas também especificamos quem é o proprietário dos arquivos que correspondem a esses padrões. E ao habilitar essa opção, chamado nos seria automaticamente solicitado para revisão. Sempre que alguém levanta um pull request que modifica o código de sua propriedade. Eu sei que isso parece confuso. E é por isso que vou demonstrar rapidamente o mesmo fósforo. Vamos ao nosso repositório. E eu estou no ramo principal aqui, vou criar um novo arquivo. Vou nomear o arquivo como código ou enfermeira. Tem que ser exatamente o mesmo nome, todas as letras maiúsculas. E dentro desse arquivo, vou especificar um dos proprietários com um padrão. Por exemplo, eu poderia dizer star dot js e todos os arquivos com extensão dot js seriam propriedade de vamos dizer, olha, nós já olhamos para ele como um dos colaboradores para resolver este projeto. Então, onde quer que você vá adicionar como proprietários, eles precisam ter permissões de gravação para este projeto. Então, deixe-me copiar rapidamente o endereço de e-mail do Luke e colar aqui. Você também pode adicionar o nome de usuário de Luke. De qualquer forma, Luke agora será o dono de todos esses arquivos. Deixe-me ver esse arquivo. Agora, deixe-me tentar apagar solicitações pull com o arquivo ab.js 1. Segundo, deixe-me criar rapidamente uma ramificação aleatória. E deixe-me adicionar rapidamente um novo arquivo. Scripts ponto js. Converta o arquivo. Agora vamos em frente e aumentar a solicitação pull. E no momento em que eu fizer isso, você verá aguardando a revisão do proprietário do código da Luke's under Corp. Agora, se você for para a conta de Luke, se eu clicar no pull request, esta é a conta de Luke. Olha vai dizer esta mensagem dizendo que ele precisa revisar um pull request. Então, desde o fato de que Luke é o proprietário de todos os arquivos dot js e alguém levantou o pull request no mesmo branch em que Luke foi adicionado como o proprietário desses arquivos, get perguntou automaticamente Luke para revisar as alterações ou o pull request. Então olhe, agora posso fazer algo com esta revisão. Digamos que ele tenha aprovado as mudanças. E agora podemos ir em frente e mesclar todas as mudanças. Essa opção já está habilitada. Eu já tinha habilitado e salvo as alterações. E, portanto, isso entrou em vigor. Se desativarmos isso, Luke não estaria recebendo a solicitação de revisão. Vamos voltar ao repositório. Geralmente, mantemos o arquivo dos proprietários do código no branch base ou no branch padrão. Como esse arquivo está atualmente colocado no branch principal, o gerente ou alguém levanta o pull request pedindo para mesclar as alterações nesse branch. É quando esse código em uma espiral entraria em vigor. Portanto, você gostaria de manter esse arquivo em uma ramificação qual os desenvolvedores contribuiriam com seu código. Fim. A propósito, existem outros padrões que podemos usar para os quais você pode adiar para a documentação oficial, também estão em notas fornecidas, fornecendo alguns dos padrões de exemplo, juntamente com alguns descrição. Vou manter isso como uma nota que você pode baixar e dedicar seu tempo tentando entender isso. Na verdade, é bem direto. Os padrões são muito semelhantes aos padrões que incluímos no arquivo dot gitignore. Exceto que também vamos especificar que os proprietários têm dois chifres de arquivos correspondentes a esses padrões. Você também pode especificar equipes. Portanto, a equipe seria proprietária de um conjunto específico de arquivos. Como neste caso. Se você fizer uma associação de debate do GitHub para sua organização, também poderá adicionar considerações. Espero que faça sentido. Vejo você a seguir. 113. 1503 Mandando a resolução da conversa antes de mesclar: Ok, vamos falar sobre essa regra de previsão de ramificação que diz que é necessária a resolução da conversa antes da fusão. E, a propósito, vamos ignorar falar sobre essa opção porque isso tem algo a ver com ferramentas externas. E, basicamente, se você quiser realizar muitos tipos de verificações antes de mesclar o código em outra ramificação, convém habilitar isso. E falar sobre isso está definitivamente fora do escopo deste curso específico, porque isso tem algo a ver com ferramentas externas. Mas, de um modo geral, se você quiser realizar qualquer tipo de verificação, como verificação de vulnerabilidade, está verificando se há erros programáticos no código. Nós realizamos integração contínua ou talvez implantamos o código em um servidor de compilação, obtemos o status da compilação, etc. Se você quiser trabalhar para muitos desses tipos de coisas, sempre que alguém fizer um pull request, você pode configurá-los aqui. E isso, na verdade, depende completamente dos padrões da sua organização e precisamos seguir de acordo. Então, talvez abordemos tudo isso em outros cursos de DevOps, mas vamos ignorar isso por enquanto. Vamos voltar a essa opção que diz que é necessária a resolução da criminalização antes da fusão. Deixe-me ativar essa opção. Demonstre a você o que isso significa exatamente. Então, basicamente, os homens usam a senha bem rápido. Portanto, essa opção está habilitada. Deixe-me ir para os pull requests que havíamos levantado anteriormente. E como você pode ver, atualmente podemos realizar a mesclagem porque a visualização deles já está concluída. Mas digamos que o Sr. Luke tenha um comentário a acrescentar no código. Então, vamos para a conta do Luke. Deixe-me abrir o arquivo dessa solicitação pull. E digamos que temos várias linhas de código aqui. E Luke está fazendo algum comentário. Então, talvez algo parecido com algo desse tipo. Deixe-me ampliar um pouco. Então, eu quero adicionar esse comando, e vamos clicar em qualquer um desses botões. Deixe-me adicionar um único comentário. E como tínhamos habilitado essa opção de regra de proteção de branch, se eu voltar para a pull request da conta do remetente, deixe-me recarregar a página. Você verá que a mesclagem está bloqueada Mais uma vez porque há conversas não resolvidas. Vamos supor que o remetente tenha abordado esse comentário e ele mencionará a mesma resposta para olhar. Sim, eu verifiquei isso. Algo desse tipo. Isso é mais uma vez, volte para a conta de Luke. Ele foi ver a resposta aqui. E quando você estiver satisfeito com a resposta, Luke resolverá a conversa. É mesmo. Em seguida, o remetente pode realmente mesclar a pull request. Se essa opção não estiver habilitada, dissolução da conversa não será necessária para mesclar o código. Vejo você a seguir. 114. 1504 Explorando todas as outras regras de proteção de ramos: Vamos falar sobre todas as regras de proteção de filiais restantes aqui. Eles são muito fáceis de entender e já são diretos. E assim podemos encaixar tudo isso apenas neste vídeo. Sair desta regra de previsão de ramificação diria que é necessário combates assinados. Na verdade, isso exige que você entenda quais são os commits atribuídos, como podemos gerar chaves privadas e públicas para assinatura, criptografia, descriptografia, etc. Então, isso deserta no capítulo próprio. Então, vamos falar sobre isso no próximo capítulo. Mas vamos encerrar este capítulo sobre a regra de previsão de ramificação depois de tocar rapidamente em todas as outras opções que temos aqui. Portanto, temos essa opção que diz que o histórico linear necessário. E, como o nome sugere, ele não nos permite ter commits de mesclagem. Se você tiver um commit de mesclagem, não teríamos mais um histórico de commit linear. Então, digamos que eu tenha habilitado essa opção. Deixe-me salvá-lo bem rápido. Se você voltar às solicitações pull, deixe-me clicar aqui. Esses são os pull requests que levantamos anteriormente. Agora, se eu escolher essa opção para criar um commit de mesclagem, você verá esta mensagem dizendo que o branch Merge requer histórico linear. Isso porque tínhamos habilitado essa opção. Mas ainda assim podemos ver essa opção para mesclar pull request. Isso é porque eu estou realmente fazendo isso a partir deste segundo, quem é o dono do repositório? Deixe-me editar essa regra de previsão de ramificação. Temos mais uma opção para não deixar que isso aconteça. Então aqui está. Se habilitarmos essa opção que diz não permitir ignorar, ambas serão configurações. E a descrição diz que as configurações de cotovelo serão aplicadas a administradores e funções personalizadas com a permissão ignorar proteções de ramificação. O que isso significa é que até agora todas as regras de produção do branch não são realmente aplicadas para administradores, não são realmente aplicadas para administradores ou para os proprietários do repositório. Ao habilitar essa opção, os administradores são os proprietários do repositório, não podem realmente ignorar as regras de produção do branch. Deixe-me ativar essa opção e salvar as alterações. Agora, se eu voltar para o pull request, o Remetente sendo o administrador do repositório, não poderá mais escolher essa opção. Isso ficou acinzentado. Também não consigo clicar nele. Se você pegar a licença da organização do GitHub, você deve ser capaz de criar uma equipe de indivíduos. Alguns deles são Edmond, alguns deles são mantenedores. Eles podem ter papéis diferentes. E ao habilitar essa opção, as regras de previsão de ramificação impostas por um ano de idade fornecidas aos administradores são a manutenção do repositório. Entre essas duas opções, temos essa opção que diz que as implantações necessárias devem ser bem-sucedidas antes da fusão. Bem, você pode usar essa regra para garantir que as alterações sejam implantadas com êxito sem problemas nesta preparação ou nos testes e Romanos antes que as alterações possam ser mescladas no branch padrão. Agora, isso depende da sua organização das ferramentas que você está usando. Atualmente, não temos nenhuma implantação e configuração romana. Então, nós realmente não podemos demonstrar isso. Talvez esse seja o tópico de outro curso. Então, vamos pular isso. E ficamos com algumas opções de regras de previsão de ramificação. E essas opções são aplicáveis a todos, incluindo administradores. Olá, empurrões forçados significariam que queremos carregar os empurrões de força nos galhos protegidos. E podemos até escolher quem pode fazer isso. Se queremos permitir que todos com eixo push, como colaboradores, por exemplo? Ou queremos escolher especificamente quem queremos um empurrão de força baixa? Por exemplo, Luke já foi adicionado como um dos colaboradores. Eu posso escolhê-lo, por exemplo, se eu quiser. E, finalmente, temos uma exclusão de carga. Então, ao ativar essa opção, estamos permitindo que as pessoas com Bush Axis possam excluir as ramificações que correspondem a esse padrão. Nesse caso, estamos dizendo que todas essas regras de previsão de branch são aplicáveis ao branch principal. Assim, ao habilitar essa opção, estamos permitindo que as pessoas com acesso push possam excluir esse branch específico nesse caso. Então, isso é tudo sobre as regras de proteção de filiais. Mais uma vez, vamos explodir essa opção. No próximo capítulo. Vejo você a seguir. 115. 1601 Mimicing os commits e a necessidade de ter commits vetified: Agora deixe-me demonstrar algo realmente interessante. Tenho certeza que você ficaria surpreso ao ver isso acontecendo. Para esse exemplo, vou usar um dos repositórios existentes que estamos usando ao longo deste curso. No caso de você ter perdido o controle do que é esse repositório. Pense nisso como um repositório aleatório com vários arquivos nele. Atualmente, este projeto tem esses dois colaboradores. Temos um remetente que é o proprietário do repositório e Luke, que é um dos colaboradores deste projeto. Também por causa deste exemplo, desativei as regras de produção da filial para a filial principal. E, portanto, você está vendo essa mensagem que diz que seu branch principal não está protegido. Agora, uma pergunta para você. É possível que o Sr. Luke faça um comentário em nome do cilindro sem o seu consentimento? Bem, vamos dar uma olhada. Imagine que este é o computador do Sr. Luke. E para economizar seu tempo, eu já clonei o projeto. Deixe-me abrir o Git Bash aqui. Deixe-me executar o comando git config para não dar uma olhada nas configurações atuais. E como você pode ver, nome de usuário e e-mail estão desativados. usuário do Sr. Luke é Luke's in the Corp e o endereço de e-mail é o endereço de e-mail visual. Deixe-me tentar mudá-los para Saunders. Eu vou dizer git config global username. Vou dar a mesma dose de nome de usuário do GitHub, assim. Da mesma forma, também vamos alterar o endereço de e-mail e atualizá-lo com alguns desses endereços de e-mail. Posso obter isso facilmente com esse nome e endereço de e-mail. Mas no comando git log. E dando uma olhada em alguns dos comentários feitos pelo Sr. Cilindro. Agora, se eu fizer git config list, você verá que o nome de usuário e o endereço de e-mail ou não, atualizado com cilindros é um nome e seu endereço de e-mail. Deixe-me agora tentar fazer um commit e ver o que vai acontecer. Deixe-me criar rapidamente um arquivo com algum nome aleatório. E eu vou ficar como esse arquivo bem rápido, git add name of the file. E finalmente git commit com alguma mensagem. Vamos chamá-lo de commit errado. E também vou fazer push dessas alterações no repositório do GitHub. Agora vamos ao GitHub e dar uma olhada em como as coisas se refletiram por lá. Atualmente, estou na filial principal. Deixe-me recarregar a página e ir para o commit. E como você pode ver, podemos ver o compromisso que acabou de ser feito pelo Sr. Luke. Mas se você notar o que está sendo mostrado aqui, diz que esse compromisso foi feito pelo Sr. Sunda e está apontando para o perfil de cinzas. Curiosamente, alguns que não têm ideia de que esse comentário foi feito. Para alguém que olha para o histórico de commits. Eles vão pensar que esse comitê é realmente feito por Sunder o dia todo, não é ele que realmente fez esse comentário. Isso está acontecendo porque o bem presume que o que eles estão usando? Um endereço de e-mail que foi definido nas configurações é a mesma pessoa que está realmente fazendo o commit. No entanto, isso pode não ser o caso. E acabei de demonstrar isso para você. Isso não precisa necessariamente ser feito pelos colaboradores existentes do projeto. Alguma pessoa aleatória para o projeto, e levante o pull request com monte de commits imitando que esses comentários foram realmente feitos por algum outro usuário, o que obviamente não é algo que esperaríamos que acontecesse. Portanto, precisamos de algum tipo de processo de verificação que verifique se o autor do commit é a mesma pessoa que realmente fez parte do comitê. E é aí que os commits verificados entrarão em cena. E é sobre isso que vamos falar a seguir. 116. 1602 Compreender as assinaturas digitais: Antes de entendermos o que nosso signo compromete, vamos tentar entender o que exatamente é uma natureza distorcida. Não no contexto do Git e do GitHub. Mas em geral. Suponha que temos Bob e Alice. E Bob quer enviar um arquivo para Alice. Se ele enviar o arquivo como está para Alice, então pode acontecer que alguém interfira na rede, manipule o arquivo antes que ele chegue até Alice. E Alice não tem como verificar se o arquivo foi manipulado ou se Bob é realmente o remetente. Então, tendo isso em mente, Bob fará algo a respeito. O que vai fazer é que ele vai usar algum tipo de ferramenta para criar a chamada chave pública. E uma chave privada. chave privada, como o nome sugere, não deve ser compartilhada com mais ninguém. Vai ser com Bob. E vai mantê-lo com segurança em algum lugar em seu sistema de arquivos local. Por outro lado, a chave pública pode ser compartilhada com qualquer outra pessoa. Qualquer pessoa que queira receber a mensagem ou o arquivo de Bob pode, na verdade, ter uma cópia da chave pública. Nesse caso, Bob compartilhará a chave pública com Alice. Alice dá seria útil em pouco tempo. Então, desta vez, antes de Bob enviar o arquivo para Alice, vai usar sua chave privada para assinar digitalmente o documento. Mas qual é a distância dessa natureza? Bem, a assinatura digital é essencialmente um hash dos dados criptografados, mas a chave privada do signatário. Já falamos sobre haxixe em uma das palestras anteriores. Mas, apenas para resumir, valor de hash é um valor numérico de um comprimento fixo que identifica exclusivamente os dados. Ou, neste caso, esse arquivo. Se você fizer os mesmos dados ou o arquivo como uma entrada para a função hash, ele fará exatamente o mesmo valor de hash exclusivo não importa quantas vezes você o faça. Mas se você alterar os dados ou o conteúdo do arquivo, mesmo que um pouco, a função hash retornaria um valor de hash totalmente diferente. Então, essencialmente, o valor de hash identifica exclusivamente um dado ou um arquivo. Quando digo arquivo de dados ou uma mensagem, todos eles significam a mesma coisa. Então Bob enviaria o arquivo para Alice pela rede. Agora Alice tem que verificar se a mensagem foi manipulada pelo remetente está realmente bombardeada. Eu queria que você fizesse isso. Bem, ela vai usar a chave pública de Bob para descriptografar a assinatura digital para extrair o valor do hash dela. Bem, quando eu digo que ela vai fazer isso, não é exatamente ela quem vai fazer isso. Ela vai usar algum tipo de ferramenta que faz isso. Ela então usaria algum tipo de ferramenta para descobrir o valor de hash do arquivo enviado também. Esses dois valores de hash são exatamente os mesmos, então podemos ter certeza de que os dados não foram manipulados. E se ela não conseguir descriptografar a assinatura digital, isso significa que outra pessoa enviou o arquivo usando sua chave privada e não a chave privada de Bob. Se a assinatura digital for assinada com a chave privada de outra pessoa, Alice não seria capaz de descriptografar a natureza discursiva usando a chave pública de Bob. Dessa forma, ela pode ter certeza de que o arquivo não foi manipulado e que o arquivo está realmente vindo de Bob. Se você entendeu isso, entender a assinatura verificada não deve ser um grande problema. Falaremos sobre assinaturas verificadas a seguir. 117. 1603 Compreender os Commits assinados: Agora vamos falar sobre confirmações verificadas. O conceito de comentários verificados não é diferente do conceito de assinaturas digitais que falamos anteriormente, exceto no lugar de Bob Dylan para substituir Alice. Vamos ter o GitHub. E no lugar desse arquivo, vamos ter a vírgula. Vamos supor que Luke queira atribuir um commit distal e fazer push dele para o repositório do GitHub. No GitHub, queremos verificar se esse commit realmente veio do Mr. loop. Então, inicialmente, Luke vai gerar chaves públicas e privadas, vai fazer upload de sua chave pública em sua conta do GitHub. E ele vai usar a chave privada para assinar os comentários. Mais uma vez, não é exatamente Luke quem faria tudo isso. Tudo seria resolvido pelo get, apenas executando um comando simples. Quando ele executa esse comando, o git vai essencialmente atribuir o commit distal. E uma vez após o loop faz push do commit para GitHub no site do GitHub. Github verificará se ele veio de Luke usando sua chave pública. Vamos dar uma olhada nos detalhes das etapas envolvidas em todo esse processo. Então, inicialmente chave local, de gênero, pública e privada usando alguma ferramenta, ele então carregaria a chave pública em sua conta do GitHub para que GitHub possa usá-la para verificar os commits. Distal local atribui o commit usando sua chave privada. Simplesmente executando um comando. Luke então fará push das alterações para o GitHub. Github verificará o commit usando a chave pública de Luke. Se o GitHub não conseguir descriptografar os Comanches e parecer chave pública. Isso significa que o comediante veio do Sr. Luke. Outra pessoa pode ter feito esse commit não ser sua chave privada. Vamos ver toda essa inação a seguir. 118. 1604 Como criar chaves públicas e privadas usando GPG: Ok, vamos ver como podemos criar chaves públicas e privadas. Agora suponha que este é o computador do Sr. Luke, e ele agora está planejando criar chaves públicas e privadas para si mesmo para que elas possam ser usadas mais tarde no tempo para verificação. Para criar essas chaves, vamos usar uma ferramenta chamada GPG, significa GNU Privacy Guard. E é algo que você não precisa instalar separadamente. Se você já tem o Git instalado no seu computador e já vem com a ferramenta GPG. E você não precisa instalá-lo separadamente. Caso você não esteja usando o Git Bash, do que com uma rápida pesquisa no Google, você poderá encontrar instruções sobre como instalar o GPG para o seu sistema operacional. No entanto, nesse caso, usaremos o Git Bash para o mesmo. E também certifique-se de não executar esses comandos na pasta do repositório. Para isso, criei uma nova pasta na minha área de trabalho e é aqui que vou executar os comandos. Então, primeiro de tudo, vamos garantir que o GPG esteja realmente instalado executando o comando GPG dash dash version. E isso deve mostrar uma saída como essa. Agora vamos executar o comando para criar as chaves pública e privada para o Sr. Luke. O comando para isso é GPG, traço, traço, traço, gerar chave. Isso vai nos levar a algumas perguntas. Vamos ver o que podemos responder a eles. Aqui precisamos escolher o algoritmo que queremos usar para gerar as chaves. Gpt suporta todos esses algoritmos listados aqui. O padrão é o algoritmo RSA e é o algoritmo que eu recomendo usar. Então, vou simplesmente pressionar Enter para escolher a opção padrão, que neste caso é o algoritmo RSA. Em seguida, fomos solicitados a inserir o tamanho da chave. O tamanho máximo da chave que podemos inserir é de 4.096 bits. E esse é o requisito mínimo para o GitHub. Então, vamos dizer 4.096. Pressione Enter. Aqui está nos pedindo para inserir por quanto tempo o caso deve ser válido. Eu quero que seja válido para sempre. Vou deixar a opção padrão, que é 0. Então eu nunca iria expirar. E devemos ser capazes de usar essas chaves para sempre até o momento em que as excluirmos ou fizermos algo com elas. Vamos pressionar Enter para usar a opção padrão. Agora ele está nos pedindo para nos conformar se realmente pretendemos não expirar a chave, eu digitaria y, apenas diga sim, pressione Enter. Agora ele está nos pedindo para inserir o ID do usuário. Aqui. Vou fornecer o nome de usuário da conta do Sr. Luke no GitHub. Eu já tenho isso à mão. Eu vou simplesmente copiar e colar aqui. E, claro, no seu caso, você precisa inserir seu nome de usuário do GitHub. No próximo prompt, vou fornecer o endereço de e-mail do Luke. No seu caso, você deseja fornecer seu endereço de e-mail usado para se registrar no GitHub. Então, basicamente, qual é o nome e o endereço de e-mail que você deseja usar para fazer seus commits? Deveria fornecê-los aqui. Opcionalmente, também podemos fornecer um comentário, mas eu não gosto de fornecer nada. Então eu apenas pressionei Enter. Agora ele está nos pedindo para verificar o ID do usuário que acabamos de inserir. Portanto, verifique novamente e verifique se está correto. Depois de tirar a camisa, basta digitar o personagem o para dizer L K. As chaves estão sendo geradas. Agora você pode receber um aviso solicitando que você insira a senha. Essa é apenas uma segurança adicional para proteger sua chave privada. Se alguém roubar sua chave privada, ele deve saber essa senha para poder usar sua chave privada. Isso é apenas como uma medida de segurança adicional. Você pode simplesmente pressionar OK sem digitar nada. Dessa forma, você não tem nenhuma senha. No entanto, é obviamente recomendado que você forneça uma senha. No meu caso, estou simplesmente entrando para o cacto, o que não é tão seguro. Se você quiser mais seguro, então dê uma senha muito forte com combinação de caracteres, números, símbolos, etc. E meu palpite será apenas quatro caracteres. Está tudo bem? Você recebe outro aviso avisando que a senha não é muito segura, pois é muito fácil de adivinhar. Mas eu gostaria de usar esse de qualquer maneira. Então eu escolho essa opção que diz pegar essa de qualquer maneira. Ele está me pedindo para digitar novamente a senha. Eu vou fazer exatamente isso e clicar em OK. Agora, enquanto a tecla está sendo gerada, é recomendável que você execute algumas atividades em seu computador, como mover o mouse, inserir algo no teclado, etc. E é isso que está sendo recomendado aqui. Ele diz que precisamos gerar muitos bytes aleatórios. É uma boa ideia realizar algumas outras ações, como digitar no teclado, mover o mouse, utilizar isso, isso, etc. para que a tecla gerada seja mais aleatória. Então, ambas as chaves foram geradas. Você pode verificar se eles foram gerados executando o comando GPG com a opção list case. Então eu vou dizer teclas de traço, traço, lista, traço GPG . Então, isso mostrou a chave pública. E se você disser list dash, caso secreto, isso exibirá os detalhes sobre a chave privada. Esse não é o caso real. Esses são apenas os detalhes sobre as chaves. Isso será útil em pouco tempo. Vejo você a seguir. 119. 1605 Exportando chave pública e atualizando a chave GPG no GitHub: Ok, Agora que criamos chaves públicas e privadas, vamos tentar exportar a chave pública para que possamos colocá-la na conta do Luke no GitHub. E o comando para isso é, você vai definir o GPG. Hifenato significa armadura. Esta opção é exportar a chave no formato ascii ou mode em vez de binário. E então vamos dizer traço, traço, exportá-lo para exportar a chave. Em seguida, vamos especificar o ID da chave. Agora, qual é o ID da chave dos nossos comandos anteriores? Se você notar, onde verificamos a criação da chave pública e da chave privada, ele também imprimiu o ID da chave. E se você perceber, a ideia-chave das chaves pública e privada é exatamente a mesma. Isso ocorre porque a chave privada não tem ideias-chave separadas, como. E assim, o GPG está apenas mostrando o ID da chave pública para a qual a chave privada é paga. Vou simplesmente copiar esse identificador. Como alternativa, você também pode usar UID significa ID de usuário, e também podemos usar o mesmo. Mas geralmente é recomendado que você use o ID da chave em vez do UID. Resumindo, isso pode causar conflitos se você tiver um KeyStore. Então, vamos usar isso para exportar a chave pública. Podemos copiar o texto do bloco de chave pública begin PGP. Todo o caminho até este ponto em que vemos o bloco de texto e chave pública PGP. Eu vou simplesmente copiá-lo. Como alternativa, você pode executar o mesmo comando. E usando chaves angulares, podemos exportar a chave pública em seu arquivo. Chave de ponto pública, por exemplo, onde o público que você seria exportado. Se desejar, você também pode exportar a chave privada. No momento. Não precisamos fazer isso. Mas estou apenas demonstrando como podemos fazer isso. Então, em vez de dizer apenas exportar, vamos dizer exportar chave secreta do traço. E isso exportaria a chave privada também. E quando você fizer isso, você receberá uma mensagem solicitando que você insira a senha. No meu caso, é apenas para frase-senha de personagem. Quais são as senhas que você criou? Pretendia isso aqui. Depois de clicar em OK, temos a chave privada despejada neste arquivo. Então, vamos ver se podemos ir lá. Se eu abrir esse diretório, você verá esses dois arquivos criados. Vamos abrir o arquivo de chave de ponto público com o Bloco de Notas Plus, Plus. E você verá o mesmo texto que foi visto no Git Bash. Eu vou simplesmente copiar isso. E agora vou para a conta do Luke no GitHub. Isso parece conta do GitHub. Vou clicar nesse ícone. E se você rolar um pouco para baixo, você verá Configurações. Clique nisso. E no menu do lado esquerdo, clique em, clique nas teclas SSH e GPG. E aqui você vê a opção. Para dar uma nova chave GPG. Na seção chave, você vai colar argamassa acabou de copiar a chave pública, título opcional de Ignacio e clicar em Adicionar chave GPG. Em seguida, veremos como podemos assinar os commits. Vejo você a seguir. 120. 1606 Como criar commit assinado Como configurar commit global que verifica commit assinado no GitHub: Ok, vamos ver como podemos fazer o commit atribuído e fazer com que eles sejam verificados no GitHub. Eu já tenho a mente pública CAP clonada aqui. Deixe-me abri-los, obter o bash no diretório raiz do projeto. Deixe-me primeiro executar o comando git config list. E como você pode ver, eles usam o nome e e-mail são atualizados para o de cinzas, o que não é o ideal. Vamos ver o que vai acontecer quando nos atribuirmos a confirmação. Então deixe-me criar um arquivo aleatório, algo desse tipo. Deixe-me encenar. E, a propósito, não vou fazer isso no ramo principal. Acabei de escolher um ramo aleatório. Nesse caso, o nome do ramo é QQQ, que será criado aleatoriamente em uma de nossas palestras anteriores. Não me deixe tentar fazer designado para se comprometer. O comando para isso é git commit. Hífen maiúsculo, Sim. Certifique-se de que esteja em maiúsculas. Sim. Caso contrário, essa caminhada. No entanto, se você quiser assinar a tag , ela deve estar em minúsculas. Sim. Então hífen maiúscula sim. E hífen md para fornecer alguma mensagem para este commit. Vamos chamá-lo de meu commit ou o que quer que seja. Então, o commit falhou. E a mensagem diz que não há chave secreta. Para o Sr. Sunda. O ID de usuário da chave que criamos é para o Luke's. Mas os bons conflitos são ter as credenciais com frequência. Ambos não combinaram com Enter. Não podemos fazer um sinal para se comprometer neste caso. Então, vamos rapidamente em frente e altere as configurações. O nome de usuário será GitHub, nome de usuário de Luke. Da mesma forma, vamos atualizar os melodramas para os que parecem assim. Agora vamos tentar fazer um commit atribuído. Pela primeira vez você faz isso. Você seria solicitado a digitar a senha. Eu vou entrar exatamente isso. Acertar. Ok? E nosso compromisso com o sucesso. Vamos tentar agora enviar essas alterações para o GitHub. Então, podemos fazer push desse commit que foi para o GitHub e ver o que foi refletido lá. Atualmente, estou no meu repositório público de aplicativos e nesse ramo, QQQ. Deixe-me recarregar a página. E como você pode ver, podemos ver o comentário que acabou de ser feito. E desta vez é com crachá verificado. Portanto, o github é capaz de buscar a chave pública do Sr. Luke, o autor de O commit, para verificar se o comitê é realmente feito pelo Sr. Luke. É assim que o processo de verificação acontece. Se eu removesse a chave pública do Sr. Luke, o crachá verificado não estaria mais lá. Você pode dizer Levante-se dizendo que a verificação não foi bem-sucedida. E, a propósito, se você não quiser fazer a opção hífen S toda vez que quiser assinar um commit, podemos realmente introduzir um bom conflito para isso. Então você vai dizer git config global climate dot JPG sign. E vamos definir isso como verdadeiro. Portanto, toda vez que você quiser fazer commit de sinal, você não precisa fornecer explicitamente a opção hífen S. Se você definir esse sinalizador. Além disso, se você tiver várias chaves privadas, para evitar ambiguidades, você também precisará informar qual K12 particular usa para assinar os commits. O conflito para isso é a chave de assinatura do usuário. E você fornecerá o ID exclusivo da chave, GPG. Chaves. Você pode fornecer esse ID. Assim. Digamos que haja uma pessoa com intenção negativa. Ele criou uma chave privada usando as credenciais de Luke e presume que ele até mesmo fez push do commit para o repositório no site do GitHub. Github não poderá verificar esse commit usando a chave pública na conta do Luke. E dessa forma, levantar-se seria capaz verificar se o comitê não está realmente vindo do Sr. Luke. Espero que faça sentido. Vejo você a seguir. 121. 1607 Mandando Commits assinados Commits de assinatura do código VS: Ok, não vamos falar sobre essa regra de previsão de ramificação que tínhamos deixado de fora antes. Diz que confirmações assinadas obrigatórias. Você já deve ser capaz de entender isso. Se você habilitar essa opção, o que isso significa é que só queremos permitir cometas de sinal nos ramos correspondentes. Por mais simples que isso diga, este vídeo vai ser muito filmado. Deixe-me incluir também mais uma coisa. Vamos dar uma olhada em como podemos ter assinado commits do Visual Studio Code. Para isso, deixe-me abrir este projeto usando o Visual Studio Code. Portanto, a configuração para isso é que você precisa ir ao menu Arquivo, Preferências, configurações e pesquisar. Deixe-me fazer isso de novo. Configurações e pesquisa por GPG. Você precisa habilitar essa opção que diz ativar assinatura de commit. Feche as configurações. Vamos fazer uma edição rápida em um dos arquivos apenas para que possamos confirmar algo. Eu fui colocado em algum texto aleatório, salve o arquivo. E deixe-me cometer as mudanças. Assine a partir do código VS, algo desse tipo. E deixe-me fazer o commit. Você pode ser solicitado a digitar a senha. Por favor, insira-o e clique em. Ok. Como eu já fiz isso antes, não recebi esse aviso mais uma vez. Mas se você acessar o GitHub agora e recarregar a página, é claro, precisamos fazer push dessas alterações para poder vê-las no GitHub. Então, vamos fazer isso rapidamente. Vamos recarregar a página. E, como você pode ver, podemos ver esse commit e ele também é verificado. Espero que faça sentido. Vejo você a seguir.