Git e Github: treinamento completo para iniciantes

1. Introdução da masterclass Git: Bem-vindo ao melhor curso de TI. Neste curso, vamos aprender do zero até conceitos mais avançados. Começamos com o que é? Por que toda empresa adora, como o Git realmente funciona, configure o Git em nosso sistema Noções básicas sobre o Git, como preparar os arquivos e confirmar a ignorância Depois disso, temos uma seção completa para navegar no histórico de commits. Nisso, podemos comparar dois commits, voltar a especificá-los, adicionando textos Depois disso, temos a seção de ramificações e fusões, que é o tópico mais importante do kit Também veremos testar as mudanças, os diferentes tipos de fusão, a resolução de conflitos como o Pro, os tipos de reset, técnica de seleção seletiva. Depois disso, temos uma seção para trabalhar em equipe, na qual mostrarei praticamente como os membros da equipe trabalham juntos Nisso, temos clonagem, preenchimento, puxar, empurrar. Além disso, alguns recursos adicionais do github, como lançamentos, problemas, marcos, contribuem em projetos de código aberto Depois disso, veremos como organizar o histórico do nosso projeto para histórico do nosso projeto pareça mais profissional, modificar os commits existentes, dividi-los e eliminá-los , muito mais coisas Portanto, neste curso, aprenderemos o Git nos dois sentidos. Primeiro, veremos a abordagem da linha de comando e, em seguida, mostrarei como podemos fazer o mesmo usando ferramentas de interface gráfica como o Gitub desktop, código do Visa Studio e o Git Gracon Mas, como você deve saber, as ferramentas GI têm poucos recursos limitados. É por isso que aprender comandos do Git é muito importante para nós. Se você não sabe nada sobre o Git ou está confuso sobre os conceitos do Git ou quer dominar o kit e o Github, então este curso é Agora você pode perguntar, quem sou eu? Sou engenheiro de software e também ensino programação em linguagem fácil de explicar usando meu canal do YouTube, Deus te abençoe, e com meus cursos on-line E neste curso, também apresentarei alguns projetos nos quais você pode praticar os comandos do kit. Como você pode acompanhar comigo , porque quando você escreve comandos do Git por conta própria e os experimenta , você entenderá os comandos corretamente Cometer erros, aprenda com os erros e faça isso até dominar essa habilidade Depois de concluir este curso, você entenderá adequadamente como o kit funciona e o usará com confiança , sem se confundir e usando as melhores técnicas Eu sei que você está animado para aprender isso e o Github, então entre e mergulhe neste curso 2. O que é Git e Github?: Então, antes de começarmos a aprender a andar, vamos ver o que é o Git O Git é o sistema de controle de versão mais popular. Agora você pode perguntar o que quero dizer com sistema de controle de versão. O sistema de controle de versão significa que ele nos ajuda a registrar diferentes versões do nosso projeto. Deixe-me explicar com um exemplo do mundo real. Imagine que você esteja trabalhando em um aplicativo de comércio eletrônico. Agora, depois de algum tempo, você realmente estragou seu código e não consegue identificar erros e não consegue resolvê-los. Você decide começar do zero. Agora, qual é a solução para que essa situação não aconteça novamente? Uma solução é duplicar seu projeto e dar a ele um nome como versão 1.0 E guarde-o em algum lugar como backup. Então, se no futuro você errar novamente, você pode voltar para o código da versão 1.0 Agora, ao introduzir novos recursos, você continua fazendo backup e criando versões do seu aplicativo. Mas fazer backup manualmente leva a muitos problemas, como problemas de armazenamento. Além disso, isso cria muita confusão, como na versão 1.0, quais recursos adicionamos ou removemos. Além disso, imagine que você tem mais um membro da equipe trabalhando no mesmo projeto, depois precisa fazer seus backups e quais mudanças nesses projetos você não consegue acompanhar. Isso cria muita confusão e estresse para a equipe. Naquela época, ele aparece na foto. O kit nos ajuda a armazenar diferentes versões de nossos projetos de forma muito sistemática e sem precisar de armazenamento extra Suponha que você esteja trabalhando em um arquivo SML de pontos de índice queira fazer backup do código atual Você diz ao Git, salve esse código de arquivo no histórico. Faça uma captura instantânea do seu código e simplesmente o armazene em seu armazenamento Agora, à medida que seu aplicativo cresce, você faz várias capturas de tela e as armazena no armazenamento Git Quando você quiser ver uma versão específica , o Git mostra o histórico do seu projeto e você pode facilmente restaurar esse código Agora você pode dizer que entendemos o Git para rastrear nosso histórico de projetos, e é por isso que não precisamos nos preocupar com backups manuais, mas com a forma como eles resolvem problemas trabalhando em equipe É outro problema. Deixe-me explicar isso rapidamente. Aqui, você e os membros da sua equipe trabalham individualmente no mesmo projeto, e ambos usam o kit para monitorar o histórico do projeto. Agora, quando você terminar sua única tarefa, poderá fazer uma captura instantânea do código no Kit e fazer o upload desse projeto no serviço Cloud, o que nos permite fazer o upload de projetos do kit Agora, o membro da sua equipe obtém seu projeto ou pasta do Git desse serviço de nuvem e começa a trabalhar nisso Quando ele terminar de usar o blog, ele poderá tirar fotos e atualizar as alterações no serviço de nuvem E você consegue adivinhar qual serviço de nuvem é mais usado pelos desenvolvedores? Certo, é o Github. O Git e o Github são diferentes. Git é um sistema de controle de versão, e o Github é usado para hospedar projetos Git na nuvem e também oferece mais recursos. Ao usar o Git e o GitHub, podemos trabalhar facilmente em equipe sem enviar e-mails um para o outro. Não se preocupe. Nós entenderemos isso profundamente na próxima seção. Na verdade, temos uma seção inteira em que eu praticamente mostro como os desenvolvedores trabalham uns com os outros. Para limitar rapidamente, é o sistema de controle de versão mais popular. Com o Git, podemos acompanhar histórico do nosso projeto de forma muito eficaz Portanto, não precisamos nos preocupar com backup e recuperação manuais. Também pelo Git, podemos saber quando mudanças específicas são feitas com data e hora e também quem fez essas alterações Além disso, o Git facilita a colaboração com os membros da equipe e oferece muitos outros benefícios que veremos neste curso É por isso que quase todas as empresas querem desenvolvedores que conheçam muito bem o Git, e é por isso que todo desenvolvedor precisa aprender Git e Aqui neste curso, vamos aprender o Git muito profundamente Estou muito empolgado com isso e espero que você também esteja. Nos vemos na próxima aula. 3. Várias maneiras de usar o Git: Agora, deixe-me mostrar as várias maneiras usar o Git como desenvolvedor Então, a primeira maneira é usá-lo na linha de comando, que significa que você abre seu terminal e começa a escrever comandos para acessar o Git Essa é uma das maneiras simples e fáceis de usar o gate, e muitos desenvolvedores preferem a linha de comando. Agora, se você não gosta de usar a abordagem de linha de comando , pode usar nossos editores de código para acessar o portão Por exemplo, no código VS, por padrão, obtemos o painel de controle de origem. Usando esse painel, podemos realizar operações básicas do git. Agora você pode perguntar: e se quisermos usar mais recursos do git? Não se preocupe com isso. Temos uma extensão de código VS chamada Gitans, que é a extensão Git mais popular e mais usada Você pode ver que essa extensão foi baixada por quase 30 milhões de usuários. Você também pode usar essa extensão. Agora, outra maneira de usá-lo é usando a interface gráfica do usuário ou a GUI GI significa que podemos usar um aplicativo feito especialmente para usar o Git Atualmente, o aplicativo Git mais usado e simples é o Github desktop. aplicativo de desktop Gitub o tornou muito simples para iniciantes no Gate , mas é uma estrutura super simples e fácil de entender, mas não tem todos os recursos Se você quiser usar outra ferramenta GI, que tenha mais recursos do que o desktop Github , você pode usar o Gate gracon Essa também é uma ferramenta popular para o Git, mas sua interface de usuário é um pouco complexa do que o aplicativo de desktop Github Mas no final deste curso, você definitivamente gostará do Gate gracon Mostrarei o porquê nas próximas seções. Agora você pode perguntar: qual é a melhor maneira de usá-lo? E a resposta é a abordagem da linha de comando, e 70% dos desenvolvedores gostam de usar a abordagem da linha de comando. primeira razão é que todas as ferramentas de GI, seja para desktop Github ou Kraken, vêm com algumas limitações, o que significa que, para alguma tarefa, você definitivamente precisa usar a linha Ao usar a linha de comando, você pode realizar todas as tarefas relacionadas ao Git Outro motivo é que as ferramentas de IA nem sempre estão disponíveis para você. Por exemplo, às vezes o servidor não permite o uso de ferramentas GI para Git por algum motivo No momento, se você não conhece os comandos do Git , ficará preso nessa situação Na maioria das vezes, muitos desenvolvedores gostam usar as ferramentas de interface gráfica e a linha de comando, e eu também sou um deles. É isso que vou te ensinar neste curso. Primeiro, aprenderemos a abordagem da linha de comando e, em seguida, também veremos esses conceitos usando ferramentas de GI. Você aprenderá das duas maneiras e, em seguida, terá que escolher a ferramenta certa para a tarefa que está executando. Deixe-me contar um incidente na minha empresa em que trabalhei como engenheiro de software. Havia um cara que executava todas as tarefas do kit usando a linha de comando, até mesmo tarefas complexas. Ele acha que parece legal usar a linha de comando para todas as tarefas. Mas todos sabemos que podemos realizar essa tarefa com muito mais facilidade usando ferramentas de inteligência artificial. Então não se torne como aquele cara. Você tem que pensar de forma inteligente. Dessa forma, posso concluir essa tarefa mais rapidamente e sem me confundir. Passaremos a maior parte do tempo usando a linha de comando porque ela é mais rápida. Mas quando eu achar que usar a ferramenta I é mais benéfico , mostrarei essa forma de ferramenta GI. Além disso, muitos desenvolvedores iniciantes têm muito medo de usar a linha de comando, ou posso dizer que se lembram dos comandos para andar, mas não se preocupe, vou te ensinar tudo de forma simples, passo a passo e mais fácil do que você forma simples, passo a passo e mais fácil Você terá a confiança necessária para usar o Git como profissional. Agora, na próxima lição, veremos como instalar o Git em nosso sistema 4. Configurando o Git em nosso sistema: Então, vamos instalar o Git em nosso sistema. Mas antes disso, vamos verificar se Git já está disponível em nosso sistema ou não E para fazer isso, usamos o terminal. Portanto, se você for usuário do Windows, pressione a tecla Windows e digite CMD. E se você for Mcuser, pressione Command plus space e digite terminal Estou usando o Windows, então é assim que meu terminal ou CMD se parece Seu terminal pode ter uma aparência diferente. Isso não importa. Então, primeiro de tudo, aqui digitamos git version para saber qual pessoa do Git está instalada em nosso sistema Veja aqui que o Git não é reconhecido como um comando interno ou externo Se você estiver recebendo a mesma mensagem, ela não está instalada no seu sistema e, se você obtiver a versão, deverá garantir que a versão não seja muito antiga, como duas, ou mais antiga que duas. Certifique-se de atualizar seu gaiterson com isso, você pode acompanhar facilmente. Então, para instalar ou atualizar o Git, abrimos nosso navegador e pesquisamos aqui Abra este post no site. Agradável. Portanto, a versão mais recente do Git é 2.44 0.0 Se você estiver assistindo a este curso no futuro, poderá obter uma versão diferente, mas não se preocupe, você ainda pode seguir este curso. Confie em mim, você não tem nenhum erro. A partir daqui, você pode ver como seu sistema operacional ou podemos simplesmente clicar nesse botão. Clique aqui para fazer o download e vê-lo começar a baixar g. Lovely. Agora, vamos abrir essa configuração. Primeiro, ele pedirá permissão. Então, permita, clique em Avançar. Aqui você pode selecionar o caminho de instalação, então clique em Avançar, Avançar, Avançar e, a partir daqui, podemos selecionar nosso editor de código padrão. Vou usar o código do Visual Studio ou o VSCode porque quase 90% dos desenvolvedores usam o VSCode e Em seguida, e clique em Avançar. Em seguida, clique em Avançar. Clique em Avançar até obter Instalar e a instalação ser iniciada. Concluído e clique em Concluir. Agora, abra o menu Iniciar e pesquise Git Bash, que é a interface de linha de comando para fornecer a interface do terminal para o sistema Windows No restante deste curso, usaremos a CLI base do Git para escrever comandos do Git Se você é Mguser, então você tem que usar seu terminal porque a base é apenas para Windows Aqui escrevemos a versão Git dash dash e C, aqui temos nossa versão Git Instalamos o Git com sucesso em nosso sistema. 5. Configurar detalhes do usuário para git: Agora, para começar a usar o Git, primeiro precisamos fazer algumas configurações, como nome de usuário, EID, editor de código padrão, que já definimos durante a instalação Git e também a configuração de final de linha Não se preocupe Eles são muito simples. Agora podemos definir essas configurações em três níveis, nível do sistema, que é para todos os usuários deste computador. segundo nível é o nível global, que é para todo o repositório do usuário atual, e o terceiro nível é o nível local, que é para o repositório atual Não tenha medo, faça o que eu faço. Abra o terminal ou o itBashf de todos, escrevemos sua configuração para nível global e adicionamos Aqui, adicionamos códigos duplos e aqui eu insiro meu nome. Deixe-me ampliar um pouco usando Control e plus, ou podemos usar Control e rolagem do mouse. Bom. Agora aperte Enter. Aqui, usamos códigos duplos porque temos um espaço em nosso valor. Além disso, você deve escrever seu nome correto aqui. Seja qual for o nome que você escrever aqui, você pode ver esse nome no histórico do repositório Agora vamos adicionar e-mail da mesma forma. Pressione a seta para cima que retornará o comando anterior, e aqui no local do nome do ponto do usuário, escrevemos o e-mail do ponto do usuário. E aqui não temos espaço em nosso valor. Podemos remover esses códigos duplos e simplesmente escrevo aqui meu e-mail. Agora vamos definir nosso editor de código padrão. Como eu disse, neste curso, vamos usar o código VS. Se você não tiver o código VS, poderá baixá-lo em code.visualstudio.com Agora, de volta ao nosso Git pash, escrevemos Git config dash Aqui, também adicionamos o código de códigos duplos, que é o código do Visual Studio, espere. Agora você pode perguntar por que adicionamos aqui, espere? Esse peso fará com que nosso terminal espere até fecharmos a janela do código VS. Aqui, armazene todas as nossas configurações no arquivo de texto e, para visualizar ou editar essa pilha, escrevemos config Global E. Pressione Enter. Veja, aqui obtemos o arquivo de configuração via código. partir daqui, podemos alterar os valores configurados e, se voltarmos à nossa fase Git aqui, podemos ver que está esperando que nosso editor feche o arquivo, porque adicionamos aqui wait Vamos fechar esse arquivo de configuração do Git e ver como saímos dele. Agora, quase concluímos nossas configurações. Só temos que fazer uma configuração que seja para o final das linhas. Essa é uma configuração muito importante que muitos desenvolvedores esquecem. Essa configuração é muito útil quando você está trabalhando com plataformas cruzadas. Por exemplo, você está usando o Windows como sistema operacional e outro, seu colega usando o sistema operacional Mac Quando você adiciona um arquivo de texto ao Git para Windows, esse arquivo usa R N, que são caracteres especiais usados no TextFile para gerenciar o layout e a estrutura das linhas Mas no macOS ou Linux, arquivo de texto usa apenas N. Então, se não lidamos com a propriedade de fim de linha, temos alguns problemas estranhos Agora, para corrigir esse problema, temos uma configuração chamada autoCRLF, que é retorno de carro e alimentação Então, aqui em nosso exemplo, se adicionarmos nosso código no repositório Git, G removerá todo o retorno do carro e o substituirá pelo feed de e o substituirá pelo feed Agora, quando quisermos obter novamente o mesmo código, Git atualizará novamente nosso código com o carriage return e o line feed Então, aqui precisamos definir essa propriedade CRLF como Tru, que converte automaticamente Agora, quando um usuário de Mac ou Windows adiciona o código ao mesmo repositório , o gait não precisa atualizar esse código porque ele já está no feed de linha Aqui, para Mac e Linux, os usuários precisam definir essa propriedade autoCRLF para a entrada, que é o tipo original Não se preocupe com isso. Você não precisa entender isso tão profundamente. Basta fazer o que eu faço e você estará pronto para começar , porque definir a configuração é um processo único Em nosso Git Bach, escrevemos Git config Global. Co dot AtoSRF para True. Se você é usuário de Mac ou Linux , aqui no lugar de True, você deve adicionar uma entrada e pressionar Enter. Aqui, nossa configuração está concluída. Agora podemos começar a aprender o Git. 6. Como fazer o Git Bash parecer bom: Agora, atualmente, nosso gdbash está assim. Vamos fazer com que nosso Gitbash pareça legal. É divertido. Se você estiver usando um terminal simples no Windows, onde eu sugiro abrir o gtbash, clique com o botão direito do mouse no Gitbsh e aqui na parte inferior Aqui, podemos selecionar cores ou podemos selecionar o tema. Aqui, temos muitos temas. Então, esses são temas muito decentes. Eu pessoalmente gosto do tema Drácula. Veja, isso parece bom. Depois disso, podemos alterar a transparência e o cursor e selecionar o cursor piscante Agora vamos para a mensagem de texto. Aqui, podemos selecionar fontes. Você pode tentar alterar essas fontes. Estou feliz com a fonte atual, então posso vendê-la. Além disso, eu suavizo as fontes até ficarem completas aplico e salvo as configurações e vejo nosso Git pash ficar assim Se você quiser experimentar qualquer outro tema ou qualquer outra fonte , você também pode fazer isso. Estou feliz com as configurações. Agora vamos começar a aprender o git. 7. Seção 02 Noções básicas de Git: Bem-vindo à segunda seção do curso definitivo do Kit. Nesta seção, aprenderemos conceitos muito fundamentais do kit, que todo usuário do kit deve conhecer. Então, primeiro, começamos com a compreensão do fluxo de trabalho do kit. Você aprenderá como o Git realmente funciona, como inicializar seus repositórios, registrar o histórico do código, preparar, confirmar, conceitos muito importantes porque muitos desenvolvedores não sabem como ele funciona e depois ficam Portanto, assista a esta seção completa, mesmo que você conheça o básico do kit, porque muitos desenvolvedores realmente não entendem esses conceitos e ficam presos ao Portanto, assista a todas as aulas desta seção. Vamos mergulhar nisso. 8. Inicialize o projeto Git: Então, para começar a trabalhar com o Git, primeiro precisamos adicionar o Git em nosso projeto ou pasta Se não adicionarmos o Git em nosso projeto, como o Git deve saber qual pasta ele deve rastrear Aqui estou na pasta do projeto e aqui eu crio uma nova pasta, digamos, faixa de tarefas. Este é o primeiro nome de projeto que criei no meu curso ultimate react JS. Além disso, não se preocupe com isso. Não vamos criar nenhum projeto específico. Aqui, nosso foco principal é dominar o Git. Agora precisamos abrir esse caminho de pasta em nosso terminal ou no Git Bash Se você é usuário do Windows, clique com o botão direito aqui e você terá a opção de abrir o Git Bash Veja, abrimos nossa pasta no Git Bash e, se você for Mcuser , clique com o botão direito do mouse na sua pasta e você terá a opção abrir um novo terminal na Agora vamos inicializar o Git em nossa pasta. Aqui, simplesmente escrevemos Git nele e pressionamos Enter. Veja aqui que recebemos uma mensagem inicializada no repositório Git vazio com o caminho da nossa pasta Além disso, podemos ver aqui que obtemos master, o que significa simplesmente que nossa pasta está pronta para isso. Agora, se em nosso diretório de trilhas de tarefas, diretório significa pasta, obtemos outro diretório chamado.it Se você não conseguir essa pasta aqui, vá até a opção de visualização e marque aqui os arquivos ocultos. Por padrão, esse diretório está oculto porque não precisamos mexer nele. Mas deixe-me mostrar o que está dentro dessa pasta? Basicamente, a pasta Git armazena informações sobre o histórico do nosso projeto Veja, aqui temos várias pastas como ganchos, informações, objetos, referências e alguns outros arquivos Se você o estiver usando, não precisa se preocupar com todos esses arquivos. Esses arquivos são detalhes de implementação sobre ele, como ele armazena informações. Não se preocupe com isso. Não é nosso negócio. Nosso objetivo é usar o Git e facilitar nossa vida e é por isso que, por padrão, diretório dot Git está Se você fizer algo nesse diretório ou excluir todo esse diretório, perderá o histórico do seu projeto. Na minha empresa, um amigo meu removeu essa pasta git de seu projeto e depois tentou usar todos os comandos it, mas eles não funcionam porque a pasta.it não Deixe-me te mostrar isso. Aqui em nosso Git Bash, estamos colocando o master entre parênteses, que significa que o Git Agora, para remover o diretório Git, podemos escrever RM para remover R recursivamente F para force e escrever Pressione Enter. C, o Git foi removido desse diretório É por isso que a pasta.it é importante. Agora vamos inicializar o Git em nosso projeto novamente e, para isso, qual comando usamos corretamente, usamos o Git nele Veja, novamente, criamos nossa pasta como repositório Git. repositório Git basicamente significa que Git está rastreando o histórico desse projeto Simples assim. Agora, na próxima lição, entenderemos profundamente como o Git funciona 9. Como o git realmente funciona?: Então, aqui inicializamos nosso repositório Git. Agora vamos ver quais são as etapas mais comuns do dia a dia que os desenvolvedores fazem com ele. Vamos entender isso com um exemplo da vida real. Imagine que você está escrevendo um livro de histórias como Harry Potter. Agora, aqui, você não quer escrever nada diretamente em seu livro de histórias, você trabalha ou escreve em outro arquivo Agora, suponha que você escreva o primeiro capítulo, primeiro verifique se está correto ou não. Se não estiver correto, você faz alterações ou atualiza esse arquivo e, se estiver correto, somente então você fará uma captura de desse arquivo e o adicionará ao seu livro de histórias Esse também é o fluxo de trabalho do Git. Deixe-me explicar para você. Aqui em nosso repositório Git, que é nosso livro de histórias Agora, não queremos adicionar nosso código diretamente porque o que quer que adicionemos em nosso repositório Git, git o armazenará Começamos a trabalhar localmente, que é nossa pasta de controle de tarefas. Agora, suponha que criemos um arquivo nessa pasta e precisemos salvá-lo como histórico, assim como nosso arquivo de gravação. Agora, nesse momento, lembre-se verificamos se está tudo bem ou não antes de salvar nossa história. Aqui também fazemos o mesmo. Nós verificamos, está tudo bem ou não? Queremos adicionar ou remover alguma coisa? Essa área de verificação é chamada de área de preparação. Agora você pode perguntar por que precisamos dessa área de preparação. Sem essa área de preparação, o que quer que seja feito em nosso código local, todo o código será armazenado diretamente em nosso repositório e não teremos a chance de ver o que alteramos ou removemos em comparação com o código anterior É por isso que a área de espera é necessária. Agora, depois de adicionarmos nosso código à área de teste, se apenas satisfizermos, faremos uma captura de tela do nosso código e armazenaremos em nosso repositório Git Agora você pode perguntar: como podemos adicionar nosso código local à área de teste Ou como podemos adicionar nosso código de área de teste ao histórico do git A resposta é muito simples usando os comandos do Git. Suponha que aqui adicionemos mais um arquivo chamado index dot gs. Queremos adicionar esse arquivo na área de preparação. Aqui escrevemos o comando, Git add, e aqui escrevemos nosso nome de arquivo index dot js Aqui, também podemos adicionar vários nomes de arquivos. Ao usar esse comando, adicionamos nosso código na área de teste Uma coisa que quero deixar claro é área de armazenamento não é uma pasta qualquer A área de teste é apenas uma memória temporária que o Git nos fornece. Muitos desenvolvedores chamam a área de teste de índice. Aqui verificamos se nosso código está correto ou não. Se não estiver correto, podemos atualizá-lo ou corrigi-lo porque não queremos armazenar código no histórico com erros. Agora, se estivermos prontos para armazenar esse arquivo em nosso histórico, tiraremos um instantâneo da área de teste e o armazenaremos no histórico do Git usando Git GamTTH é a abreviação Aqui escrevemos nossa mensagem que queremos armazenar com esse instantâneo No futuro, saberemos o que adicionaremos nesse Kummet. Confirmar significa salvar um instantâneo no histórico do Git. Por exemplo, no futuro, se corrigirmos bugs ou adicionarmos novos recursos, adicionaremos uma mensagem de confirmação para cada Camt , que diz claramente o que fizemos naquele kat que diz claramente o que fizemos naquele kat Com isso, podemos facilmente dar uma olhada em nosso histórico de código. Certifique-se de que toda vez que você cometer alguma coisa, adicione uma mensagem significativa. Cada confirmação que fazemos é armazenada com ID, data e hora, nome do autor, e-mail e nossa mensagem de confirmação exclusivos data e hora, nome do autor, . A partir desses detalhes, podemos ver quais mudanças foram feitas por quem e quando. Agora, suponha que adicionemos aqui outro arquivo chamado ponto de dados TXT. Diga-me o que precisamos fazer para armazenar esse novo arquivo no histórico. Certo. Primeiro, adicionamos nosso código à área de teste com o Git add data dot E depois disso, podemos tirar um instantâneo dessa área de preparação atual e armazená-la no repositório Git usando o Git Commit, adicionando o ponto de dados Aqui, quero esclarecer uma coisa: depois de enviar o código da área de teste para o repositório git, nossa área de teste não ficará vazia Permanecerá o mesmo que nos comprometemos. Se, no futuro, adicionarmos ou removermos algo em nosso código local e depois adicionarmos em nossa área de teste, somente os arquivos serão atualizados. Para recapitular rapidamente a classificação do código em nosso histórico do git, primeiro adicionamos nosso código à área de teste e, depois disso, se estivermos satisfeitos com nosso código atual, somente então confirmaremos esse código em nosso repositório Git e o repositório Git armazenará repositório Git e o repositório Git armazenará comandos Simples assim. Não se preocupe se você ficar confuso ou tiver muitas perguntas, você obterá todas as respostas medida que avançarmos neste curso, e aposto que você dominará o Git como P. Nesta seção, trabalharemos praticamente com esse fluxo de trabalho do Git 10. Exercício: fluxo de trabalho do Git: Na lição anterior, você aprende o fluxo de trabalho básico. Agora eu quero que você desenhe a figura aproximada ou fluxo de trabalho aproximado da marcha com os dois comandos Complete um pequeno exercício, mas a condição é que você não possa assistir à lição anterior. Tente se lembrar e depois desenhe no papel ou em qualquer lugar. Se você desenhar em papel, poderá tirar foto e enviá-la na seção de perguntas e respostas Vou tentar verificar e responder ao seu envio. Depois de concluir este exercício, você poderá ver a lição anterior e verificar se o fluxo de trabalho está correto ou não. É um pequeno jogo. Não se preocupe em perder ou ganhar. 11. Adicionando arquivos à área de palco: Agora, deixe-me mostrar praticamente como podemos adicionar arquivos à área de costura Mas antes de tudo, precisamos adicionar um arquivo em nosso código local. Abro a pasta Task Track no código VS e, primeiro de tudo, aqui, crio um novo arquivo chamado Chapter One Dot TXT E aqui escrevemos Hello. Estou criando aqui um arquivo XD, mas você pode criar qualquer arquivo. Salve esse arquivo. Agora, queremos adicionar essa pilha à área de preparação. Em nossa base Git, deixe-me verificar o status atual. Se você quiser limpar os comandos anteriores , podemos escrever aqui de forma clara. Isso limpará todos os nossos comandos anteriores. Vamos verificar o status com o status do Git. Veja aqui que chegamos na filial, mestre, ainda não há commits. E obtemos um arquivo não rastreado, que é o capítulo um ponto E também está nos dando sugestões com o Command Git add, nome do arquivo Então, podemos escrever aqui, Git add, e aqui podemos escrever o capítulo um ponto TXT Se quisermos adicionar outros arquivos , podemos editar aqui com espaço, capítulo dois pontos TXT, etc Também podemos usar aqui star dot TXT, que significa adicionar todos os arquivos com extensão TXT Além disso, podemos usar aqui o Git add period, o que significa adicionar todos os arquivos Normalmente, muitos desenvolvedores usam essa forma, então podemos usar qualquer um desses comandos. Aqui eu uso o Git para adicionar o capítulo um ponto TXT. Agora, aqui não vemos nada, mas como podemos verificar se esse arquivo foi adicionado ou não na área de teste Você pode me dizer que acabamos de usá-lo? Podemos usar o status do Git. Veja aqui que as mudanças de mensagens se transformarão e pronto. Adicionamos nosso arquivo na área de preparação. Agora, suponha que alteremos algo em nosso arquivo. Aqui eu adiciono mundo na segunda linha. E salve esse arquivo. Agora vamos verificar o status novamente, então obtenha o status e pressione Enter. Veja agora aqui que recebemos a mensagem de modificação. Atualmente, em nossa área de preparação, temos nosso código de edição anterior, que é o arquivo do Capítulo um com apenas a mensagem de saudação Agora mudamos algo em nosso código local e, novamente, precisamos adicionar essas alterações à nossa área de teste porque para confirmar nosso código no histórico do Git, precisamos passar nosso código da área de Aqui, podemos escrever novamente Git add Chapter one dot TXT. Se verificarmos novamente nosso status , não receberemos nenhuma modificação pendente. É assim que adicionamos nosso código na área de preparação. Além disso, quero dizer que, se você gosta de criar nós , pode começar a criar seus nós para comandos de porta. Também adicionarei meus nós, mas você também poderá usar seus próprios nós. 12. Vamos comprometer seu primeiro arquivo: Atualmente, temos nossos arquivos na área de preparação. Agora, vamos confirmar nosso arquivo no histórico de TI. Então, no Git Bash, escrevemos commit. Aqui podemos escrever para mensagem e, em códigos duplos, adicionamos nossa mensagem de confirmação. Digamos que o Commit inicial. Agora, aqui escrevemos uma descrição curta do nosso casaco. Mas às vezes queremos adicionar mais linhas de descrição. Por exemplo, consertamos a falha, depois podemos adicionar na descrição o que era aquela falha, e não podemos explicar isso em uma única linha. Para adicionar várias linhas de descrição, digitamos aqui only get coat. E aperte Enter. Isso abrirá um editor de código padrão que adicionamos em nossa configuração. Você se lembra? Ótimo. Agora, aqui na primeira linha, temos que inserir nossa breve descrição e, para uma descrição longa, temos que escrevê-la na nova linha. Para este commit, adicionamos uma mensagem curta como confirmação inicial, para uma descrição longa, podemos escrever e concluir o primeiro capítulo. Faça algumas modificações na história. Estou apenas escrevendo uma mensagem aleatória para demonstração. Não se preocupe Eu não vou criar um livro de histórias aqui. Agora você pode perguntar: e essas linhas? Essas linhas são comuns para explicar essa parte da descrição, não se preocupe com isso Agora vamos salvar esse arquivo e fechá-lo a partir daqui. Agora, se voltarmos ao painel do nosso kit, veja aqui que temos um arquivo alterado e duas inserções Parabéns. Fizemos nossa primeira omissão com sucesso . Para verificar isso, podemos escrever estatísticas do kit e ver aqui que não temos nada para confirmar. Limpeza da árvore de trabalho, o que significa simplesmente que nosso código de área de trabalho, código de área de teste e o instantâneo no repositório Git É assim que confirmamos nosso código no git. Você pode ver que é muito simples e fácil. 13. Quando você deve se comprometer: Agora, muitos desenvolvedores cometem um erro ao usar o git. Se eles mudarem alguma coisa na área de trabalho, eles imediatamente declaram a alteração na área de teste, que é bom, mas também confirmam todas essas pequenas alterações repositório git, o que Além disso, alguns desenvolvedores comprometem diretamente grandes mudanças no repositório git, que também é errado porque não queremos codificar por cinco dias e depois confirmar o código inteiro Não é a melhor maneira. Você pode perguntar: qual é a melhor prática para o casaco? Em primeiro lugar, quero dizer que você não se comprometa com cada mudança. Isso é inútil porque, como sabemos, o que quer que nos comprometamos, ele ficará armazenado na história Se você receber todas as pequenas mudanças , encontrar o que deseja da história se tornará muito difícil O tamanho do Camt não deve ser muito pequeno ou muito grande. Sempre se comprometa quando achar atingiu um determinado estado que deseja gravar. Imagine que confirmar código é como certos pontos de verificação que você deseja criar Se algo der errado com sua implementação atual, você poderá ir para o ponto de verificação anterior e reiniciar sua implementação Você se lembra do conceito de videogame para postos de controle? Ao concluir algo difícil com sucesso, você obtém o posto de controle que garantirá seu jogo Pense assim. Outra coisa é que cada confirmação deve representar um conjunto de cadeias logicamente separado Não misture as coisas. Por exemplo, você está resolvendo um bug e também encontrou algumas melhorias de estilo, então não precisa confirmar as duas alterações em uma confirmação Você pode fazer duas confirmações separadas, uma para corrigir o bug XYZ e depois para melhorar os estilos das placas Além disso, outra boa prática para comitês é escrever uma mensagem de confirmação significativa porque, ao enviar a mensagem, você encontrará seu ponto de verificação no histórico Então, essas são minhas fitas para casaco. Mas, no final, você é o melhor juiz de suas situações. Não pense nisso, você não cometerá nenhum erro. Todos nós cometeremos alguns erros, mas podemos aprender com nossos erros, certo? Tente se lembrar dessas fitas. Isso o ajudará em sua jornada pelo portão. 14. Exercício para o Compromisso: Agora é hora de fazer um pequeno exercício para policiar o que aprendemos nas aulas anteriores Quero que você crie um novo arquivo chamado Chapter two dot TXT e escreva algo nesse arquivo Depois de adicionar o texto, você precisa enviar esse arquivo para o repositório infantil Sei que é muito fácil e você pode concluir este exercício, seguir em frente e ver a solução. Então, espero que você conclua este exercício ou pelo menos tente resolvê-lo. Agora vamos ver a solução. Eu crio aqui um novo arquivo Chapter two dot TXT. E aqui eu simplesmente adiciono Aprender Git é uma experiência divertida. Se você sabe como o git funciona, você concorda com isso? Me avise. Salve esse arquivo e aqui retornamos ao nosso Git Bash, primeiro, qual status Veja aqui que obtemos um arquivo não rastreado que é o capítulo dois pontos TXT Temos que primeiro fazer essas mudanças e, em seguida, podemos fazer isso. Então, escrevemos Git add Chapter two dot TXT. Aqui, se você não quiser escrever um nome de arquivo completo, ao escrever o meio-nome , escrever o meio-nome , você pode pressionar a tecla Tab e ela retornará nomes de arquivos não rastreados ou modificados Isso é um pequeno truque. Depois disso, basta executar o Git commit, concluir o capítulo dois e pressionar Enter Veja aqui que fazemos outro commit, para que você possa ver como é simples e fácil confirmar o código. 15. Como pular a área de palco: Agora, a pergunta comum que muitos usuários de TI têm é podemos pular a área de teste A resposta é sim. Na verdade, não estamos pulando a área de teste, mas, como sabemos, para confirmar o código, precisamos usar esses Mas na marcha, temos outro comando, que é a combinação desses dois comandos, mas isso não é uma boa prática Faça isso somente quando tiver 100% de certeza de que não precisa revisar seu código pois esse é o propósito da área de teste Lembre-se do nosso exemplo de livro de histórias, deixe-me mostrar como podemos pular a área de Em primeiro lugar, deixe-me mudar alguma coisa no arquivo do Capítulo um. Vamos começar o capítulo um. Salve as alterações e volte para o Git Bash. Vamos verificar o status. Veja, obtemos um arquivo modificado. Agora, para confirmar essas mudanças, como sabemos, precisamos escrever dois comandos. Primeiro, temos que preparar o arquivo e depois adicionar o Commit. Mas aqui podemos escrever diretamente o Gate commit A, que é para todas as alterações modificadas e depois para a mensagem. Ou podemos simplesmente fazer isso juntos pela manhã e depois disso, podemos escrever nossa mensagem de confirmação, começando com o capítulo um. E aperte Enter. Veja se foi enviado com sucesso ao portão. Vamos verificar isso com git status. Veja, não temos nada para nos comprometer. Esse comando também adicionará todas as nossas modificações na área de teste e também confirmará esse código no repositório git Mas, como eu disse, só use esse comando se tiver 100% de certeza. 99% do tempo, primeiro preparamos nosso código e depois o enviamos para o portão. 16. Removendo arquivos de áreas: Agora, suponha que neste momento descubramos que não precisamos do Capítulo dois ou queremos excluir o arquivo do Capítulo dois. Do código VS, eu excluo esse arquivo. Bom. Agora, vamos verificar nosso status. Obtenha status. Veja, aqui podemos ver que excluímos arquivo do Capítulo dois porque excluímos nosso arquivo do diretório de trabalho, mas ainda assim esse arquivo está disponível na área de teste Deixe-me te mostrar. Então, aqui escrevemos os arquivos de Gates. Esse comando retornará todos os arquivos que estão disponíveis na área de armazenamento Veja, temos o capítulo um e o capítulo dois. Agora, como eu disse, toda vez que fazemos algumas alterações, temos que adicionar essas alterações na área de teste com o comando add Então, aqui escrevemos Gate, adicionamos o Capítulo dois para adicionar as alterações, ou podemos dizer exclusão do arquivo do Capítulo dois Agora vamos verificar os arquivos da área de armazenamento mais uma vez. Obtenha arquivos S. Aqui S significa lista. Veja, aqui temos apenas o arquivo do Capítulo um. Agora vamos verificar nosso status usando o status do Git. Veja, aqui nos preparamos para nos comprometer. Podemos escrever Git comet para mensagem, excluir o capítulo dois. E pronto. Excluímos com sucesso nosso arquivo do Capítulo dois de nossa área local e da área de teste O que quer que façamos, crie um novo arquivo ou exclua o arquivo existente, precisamos primeiro adicionar essas alterações à área de teste e, em seguida, podemos confirmar Simples assim. Agora você pode perguntar existe algum atalho ou excluir nosso arquivo da área de trabalho e da área de armazenamento e vocês estão Sim, há um comando que executa essas duas etapas em uma única etapa. Podemos escrever obter RM RM significa remover. E aqui adicionamos o nome do nosso arquivo, digamos, capítulo dois pontos TXT Além disso, podemos adicionar aqui vários nomes de arquivos e também podemos remover todos os arquivos pelo ponto estrela TXT, que significa remover todos os arquivos com extensão TXT Ao usar esse comando, podemos remover nosso arquivo da área local e da área de armazenamento 17. Como ignorar arquivos no git [GitIgnore]: Agora, às vezes em nosso projeto, temos uma pasta ou arquivo que acabamos de criar para nosso uso. Não queremos colocar isso no repositório Git. Por exemplo, se você estiver usando pacotes de nós, obterá uma pasta de módulos de nós com milhares de arquivos, então não queremos adicioná-la ao nosso repositório Git Isso aumentará o tamanho do nosso repositório sem nenhum valor Outro exemplo são arquivos temporários ou arquivos de log que não são necessários para adicionar o repositório git Deixe-me contar uma história de meu amigo, eu e meu amigo trabalhando em uma empresa corporativa. Minha amiga, Harley, não sabia sobre o portão. Ele apenas Git e Git se comprometem. Um dia, ele confirmou seu arquivo de senha pessoal com o código. Todos os membros da equipe estão vindo até sua mesa e falam sobre sua senha, mas ele não sabe como todos os membros da equipe sabem sua senha. Nesse momento, temos que ignorar esse arquivo ou também podemos ignorar a pasta inteira. Deixe-me mostrar isso na prática. Aqui em nossa pasta de controle de tarefas, criamos uma nova pasta chamada logs para armazenar registros de depuração ou de aplicativos Aqui, adicionamos um novo arquivo chamado debug dot log neste arquivo, adicionamos algum texto Este é o registro de depuração. Salve as alterações. Aqui, se você prestar pouca atenção, quando criamos um novo arquivo em nossa pasta, nosso arquivo ou pasta destacado com a cor verde no canto direito do nome do arquivo, obtemos o ícone U. Você consegue adivinhar qual é o significado desse U? Escrever? U significa arquivo não rastreado Basicamente, o VSC nos informa esse arquivo não está disponível na área de teste Não se preocupe com isso. Eu explicarei tudo isso nas próximas aulas. Agora, de volta ao nosso Gitbsh aqui, se fizermos git status, obteremos Se escrevermos aqui Git add, essa pasta de log também será adicionada à nossa área de armazenamento e não queremos isso Então, como podemos ignorar esses arquivos? Muito simples. Apenas em nosso projeto, criamos um novo arquivo chamado dot Git Ignore Certifique-se de escrever o mesmo nome de arquivo dot Git Ignore Esse arquivo também deve estar no diretório raiz do nosso projeto Em qualquer outra pasta. Só então funcionará. Basicamente, esse arquivo Get ignore informa Git quais arquivos ou pastas queremos ignorar Aqui, queremos ignorar a pasta de registros completa. Nós escrevemos logs slash. Se quisermos ignorar a pasta de módulos do nó , escrevemos os módulos de sublinhado do nó ou, se quisermos ignorar um arquivo específico , também podemos escrever logs slash debug Nós podemos fazer qualquer coisa aqui. Agora, no momento em que salvamos esse arquivo, podemos ver que o ícone U desapareceu do nosso arquivo de registros. Além disso, nossa pasta e nome do arquivo estão na cor cinza, o que significa ignorar todos os arquivos na pasta de registros. Deixe-me te mostrar mais uma vez. Eu removo essas linhas e as salvo. Veja aqui, obtemos U. E se adicionarmos novamente a barra de registros e salvá-la, então ignore esses Vamos verificar o status deles e ver se temos apenas uma pilha na trilha, que é o Gino, que acabamos Vamos adicioná-lo com Git add dot gitignore e, em seguida, Git co ignore todos os arquivos de log Adorável. Então é assim que podemos ignorar arquivos no Git. Mas lembre-se de que, usando essa forma, só podemos ignorar esse arquivo ou pasta, que ainda não foi confirmado. Em palavras simples, se quisermos ignorar nosso arquivo TXT de um ponto do capítulo um agora , não podemos simplesmente fazer isso com o arquivo Git Ignore porque nosso arquivo do capítulo um já está confirmado no repositório git Então, primeiro, temos que remover nosso arquivo da área de teste e, em seguida, podemos ignorar esse arquivo Deixe-me mostrar como podemos fazer isso? Aqui na pasta do nosso projeto, eu crio uma nova pasta chamada, digamos, Ben. E dentro dessa pasta, criamos um novo arquivo chamado backup dot Ben. Não se preocupe com esses nomes de arquivo. É apenas para demonstração. Aqui, adicionamos um texto como olá. Salve isso e veja. Aqui temos o ícone de arquivo não rastreado. Agora, deixe-me enviar acidentalmente esse arquivo. Então, em nosso Git Bash, eu escrevo Git add period, o que significa todos os arquivos e, em seguida, o Git confirma o teste But Bin file e Agora nosso arquivo já está confirmado. Vamos tentar ignorar esse arquivo. Deixe-me mostrar quais arquivos estão na área de teste usando git As Veja aqui que podemos ver que o arquivo Bupt Bin já está aqui. Então, como podemos remover esse arquivo da área de armazenamento? Na lição anterior, vimos o Git RM ser removido e adicionamos o nome do nosso arquivo, digamos, ben slash backup Mas, ao usar esse comando, ele remove esse arquivo da área de armazenamento, mas também da área local Mas aqui, queremos esse arquivo no local ou em nossa área de trabalho. Então, para obter ajuda, escrevemos H para obter ajuda. Aqui podemos ver que temos a opção dash dash cast, que só será removida do índice Índice significa área de preparação. Escrevemos Git, RM, dacast e também temos que adicionar aqui R para remoção recursiva porque queremos remover todos os arquivos Se não escrevermos aqui R, obteremos um erro. E adicionamos o diretório Bin e nossa pasta Bin é removida da área de armazenamento Vamos verificar também nossas pilhas de área de armazenamento com ela como arquivos. Veja, o arquivo Bin é removido daqui e vamos verificar nosso status. Nesse status, obtemos um arquivo excluído, mas também obtemos o arquivo de rastreamento do Bin. Aqui, temos que adicionar o diretório Ben em nosso arquivo dot Getting nor. Salve isso e veja, aqui lemos o ícone, que significa excluído. Vamos verificar o status novamente. Veja, aqui obtemos um arquivo excluído e também não modificamos nenhum arquivo porque adicionamos o diretório bin em nosso arquivo GTI bot Vamos confirmar essas alterações e confirmar, remover o diretório bin que foi confirmado acidentalmente Agora, deixe-me modificar algo no arquivo Bin. Salve isso e veja que não recebemos nenhuma mensagem de modificação, mas o arquivo gitignore permanece Você pode me dizer por quê? Vamos verificar isso com o status? Veja, aqui obtemos o arquivo gitignore modificado porque esquecemos de adicionar nosso GetI sem alterações na Não se preocupe, isso acontece muitas vezes comigo. Então, aqui, simplesmente organizamos as alterações usando o Git add period. E então o Git commit ignorando o diretório win e pronto. Assim, você pode ver como é difícil ignorar arquivos já confirmados. Portanto, a melhor prática para o Git é adicionar o arquivo Git Ignore logo no início Então vá até github.com corte o Git Ignore Aqui, obtemos todos os modelos para a opção Não obter arquivos. Por exemplo, se você estiver trabalhando com o aplicativo react, poderá pesquisar aqui node. E aqui temos um modelo para todos os aplicativos que usam node. Basta copiar este modelo e colá-lo em seu arquivo Gating Nerve. Simples assim. 18. Visualizando mudanças entre áreas: Agora, deixe-me te fazer uma pergunta. Como podemos ver as mudanças que fazemos com ele? Você pode dizer que podemos usar o comando Git status, e você está correto Mas esse comando retornará apenas o nome do arquivo. E se quisermos ver o que mudamos em nosso arquivo? Deixe-me te mostrar. Em nosso arquivo do Capítulo um, eu removo essas três linhas e adiciono aqui, este é o começo da nossa história. Salve este arquivo e chegaremos aqui para modificação. Agora, deixe-me mostrar como você pode usar outro comando it, que é itivo para diferenciar Veja, parece muito complexo ver as trocas no terminal. E se você está vendo isso pela primeira vez, então você pode quebrar sua tela. Mas deixe-me tentar te explicar. Aqui podemos ver a diferença entre capítulo um e o arquivo do capítulo B um, o que significa que está comparando mesmo arquivo com uma versão diferente Depois disso, temos o índice e alguns metadados, o que realmente não importa para nós Depois disso, obtemos essas duas linhas, as alterações no primeiro arquivo indicam com menos e as alterações no segundo arquivo indicam com mais Não se preocupe com isso. Basicamente, mostra que removemos essas três linhas vermelhas e adicionamos essa linha verde. Simples assim. Agora, como eu disse, observar as mudanças no terminal não é muito fácil. Deixe-me explicar como podemos usar nosso editor de código para observar essas mudanças? Em primeiro lugar, temos que dizer à Kat que queremos usar o código VS como ferramenta TIF Ferramentas DIF significam ferramenta diferenciada. Nós escrevemos Kit, config dash global. Estamos definindo isso como global, então não precisamos configurar para cada projeto. Depois disso, adicione a ferramenta div dot e nós a configuramos para o código VS Com esse comando, estamos apenas dando nome à nossa ferramenta DIV, que é VSCode Não se preocupe, essa configuração é um processo único. Agora precisamos dizer ao Git como iniciar o código VS. Novamente escrevemos a ferramenta Git config Global DIV. Pontos de pontuação CMD. Códigos duplos. Agora, na minha máquina, adiciono código como um caminho de código do VS, para que eu possa executá-lo em qualquer diretório. Se você não adicioná-lo ao seu caminho, não se preocupe, eu vou te mostrar em apenas um minuto. Aqui, adicionamos peso, o que fará com que nosso terminal espere. E depois disso, usamos D, que é para diferenciar ou comparar arquivos, e então temos mais dois argumentos, que são dólar local com todas as letras maiúsculas do espaço dólar remoto Esses são os espaços reservados para a cópia antiga e a nova cópia do nosso arquivo Agora vamos ter certeza de que adicionamos esse comando em nossa configuração ou não Assim, podemos ver todas as nossas configurações pelo Git config, Global E e pressionar Enter Aqui podemos ver toda a nossa configuração. Veja aqui nosso dólar local e dólar remoto não foram adicionados. Você pode adicioná-los. Salve esse arquivo e inclua esse arquivo de configuração do Git Agora, de volta ao Git Bash. Se quisermos ver mudanças no código VS, em vez de escrever Git Dev, escrevemos a ferramenta Git DV Isso comparará o que temos no diretório de trabalho e o que temos na área de preparação E está pedindo o lançamento do VSCode. Escreva sim e entre. Veja, aqui temos nosso arquivo do Capítulo Um. Agora, se você não entender as mudanças em um único arquivo, podemos dividi-lo em dois arquivos. No canto direito, temos três pontos aqui, temos que selecionar X a visualização em linha Se você ainda não conseguir arquivos lado a lado, pressione Control plus B ou Command plus B para fechar este painel do Explorer. Aqui, podemos ver claramente o que mudamos, seja, removemos essas três linhas e adicionamos essa linha verde. Esse é nosso código de estágio antigo e fizemos alterações nesse código local. Agora, se no futuro você quiser ver as mudanças, basta escrever a ferramenta Git Div Agora você pode perguntar: como podemos ver as mudanças entre o código de área de teste e o código de confirmação Fechamos essa visualização de comparação e, em nosso Git dash, precisamos simplesmente escrever a ferramenta Git Div, dash dash stage Aqui não temos nada. Você pode me dizer por quê? Porque nosso código de área de teste é o mesmo que nosso código de confirmação Temos que organizar nossas novas mudanças. Escrevemos Git add dot. Agora, executamos novamente a ferramenta Git D. Palco do Dash Dash Inicie via código, escreva sim e veja, aqui temos as alterações entre área do estágio e o código de confirmação. Para resumir esta lição, se quisermos ver as mudanças entre nosso código local e o código de estágio , usaremos a ferramenta Diff e, se quisermos ver as mudanças entre o código stagecde e o código Commit, usamos a ferramenta Di , usamos a ferramenta Di , Você está assistindo continuamente a este curso e, em minha sugestão, faça uma pausa de dez a 15 minutos na tela. Ouça música ou passe algum tempo com sua família. Cuide dos seus olhos e nos vemos na próxima lição. 19. Atalho para Status: Agora, atualmente, se quisermos ver o status atual , escrevemos git status Mas esses comandos retornam um status muito longo. Agora, há outra forma de atalho para obter status. Para isso, criamos um novo arquivo, Chapter two dot TxD e inserimos algum texto nele Além disso, mudamos algo no arquivo do Capítulo um. Agora, de volta ao nosso painel do Git e, em vez de escrever git status, escrevemos git status a para abreviar Veja, aqui temos pouco status. Isso é muito mais fácil de ver. Agora, aqui temos duas colunas, coluna esquerda e coluna direita. Essa coluna esquerda representa a área de espera e a segunda coluna representa nosso diretório de trabalho ou área local Atualmente, modificamos nosso arquivo do Capítulo 1 na área de preparação e também na área de trabalho É por isso que temos aqui tanto M quanto M para modificado. Deixe-me explicar para você de uma forma simples. Nosso arquivo do Capítulo um na área de preparação é diferente do arquivo do Capítulo um em nosso commit É por isso que chegamos aqui primeiro. E nosso arquivo de área de trabalho atual também foi modificado em relação ao que temos em nossa área de preparação É por isso que temos aqui também. Deixe-me mostrar isso na prática. Aqui, escrevemos Git add Chapter one dot TXT Se escrevermos novamente aqui, git status tem, veja, aqui não obtemos da coluna da direita, o que significa que nosso código de trabalho é o mesmo que o código E se confirmarmos o arquivo um , ele também será removido daqui. Agora você pode perguntar por que temos aqui um ponto de interrogação duplo? Porque criamos um novo arquivo. É por isso que temos aqui os dois pontos de interrogação. Vamos adicionar o arquivo do Capítulo dois na área de preparação. Git adicione o Capítulo dois TXT. Então, obtemos o status novamente. C, aqui temos A, o que significa adicionado. É assim que podemos ver rapidamente o status. Se você quiser ver o status completo, poderá usar o status do Git Se você gosta dessa abordagem , pode usar esse atalho A escolha é sua, depende totalmente de você. 20. Visualizando o histórico de confirmação: Agora, atualmente, confirmamos o código várias vezes. E se quisermos ver tudo o que se compromete? Então, para isso, aqui escrevemos, registramos e pressionamos Enter. Então, aqui temos todos os Camtes em ordem de alface até a anterior no início, recebemos nossa última Cada commit tem seu ID exclusivo que é gerado automaticamente por ele Quando quisermos acessar esse item ou ver o que está dentro desse módulo, usando esse ID exclusivo, podemos acessar esse commit específico Agora, a seguir, temos o ponto principal para dominar. Você pode perguntar qual é o ponto principal a ser dominado. Não se preocupe com isso. Eu explicarei sobre isso nas próximas seções. Por enquanto, saiba que esse git master é um nome de ramificação padrão A filial é uma área que criamos para nosso próprio uso e esse chefe está nos dizendo que atualmente estamos trabalhando nessa ramificação principal. Não se preocupe, explicarei isso detalhadamente nas próximas seções. Agora, depois disso, obtemos nome do autor e aqui recebemos o e-mail do autor. À medida que obtemos a data e a hora em que esse compromisso acontece. Aqui na parte inferior, recebemos aqui nossa mensagem de confirmação. Ao usar essa mensagem de confirmação, sabemos o que está dentro dessa confirmação, e é por isso que eu digo que você escreva uma mensagem de confirmação significativa, que você e seu colega possam entender Agora, atualmente, recebemos apenas três ou quatro detalhes de confirmação porque essas confirmações estão divididas em páginas Se quisermos ver outras páginas, pressione espaço. Veja, aqui temos nossos outros commits. Agora, para sair, basta pressionar Q. Agora, esse comando de log tem opções muito interessantes Aqui podemos escrever o log do Git, traço, uma linha. Isso retornará a lista de confirmações em uma linha. Então, aqui temos seu ID exclusivo, e somente uma breve descrição ou mensagem de confirmação. Temos outra opção, que é Git log dash dash one line, dass E veja, aqui temos nossa lista de confirmações na ordem inversa, que vai da primeira confirmação até a confirmação mais recente. Agora, o comando log é um comando poderoso para o histórico de navegação. Nós o usaremos muito na próxima seção. Na verdade, temos uma seção completa para navegar em nosso histórico de código. Por enquanto, vamos ao básico. 21. Desestagando os arquivos: Agora, atualmente, se eu verificar nosso status , aqui somos modificados para o arquivo do Capítulo um e também adicionamos um novo arquivo do Capítulo dois. Agora, como eu disse antes, nunca devemos comprometer duas tarefas diferentes em uma única confirmação. Portanto, devemos primeiro confirmar nosso arquivo do Capítulo dois e, em seguida, devemos confirmar nosso arquivo modificado do Capítulo um. Para isso, primeiro removemos o arquivo do Capítulo Um. Então escrevemos, obtemos, restauramos o estágio das e aqui escrevemos o nome do nosso arquivo, capítulo um ponto THD. Aqui, também podemos escrever vários nomes de arquivo, ou podemos escrever padrões, ou podemos até mesmo escrever um ponto final, que anulará todas as alterações em nosso código Por enquanto, aqui, queremos apenas remover o arquivo THD de um ponto do capítulo 1 Agora, se verificarmos novamente o status aqui, obteremos vermelho, o que significa que ele foi modificado no local ou na área de trabalho. Agora, é importante que você entenda como esse comando de restauração realmente funciona. O comando restore basicamente pega a cópia do próximo ambiente. Não se confunda. Deixe-me explicar para você de uma forma simples. Então, quando escrevemos git restore stage, chapter one dot ThD, basicamente, você está dizendo que queremos remover arquivo THD do capítulo um O Git faz uma cópia do próximo ambiente. Qual é o próximo ambiente após o ambiente de estágio? Lembre-se dessa figura. Commit é o próximo ambiente após o ambiente de estágio. Então, ele simplesmente pega uma cópia do nosso arquivo do Capítulo um do último comando e simplesmente a adiciona na área de preparação Mas nossa área de trabalho tem essas mudanças. Indiretamente, removemos nosso arquivo do Capítulo Um. Agora, se eu lhe fizer uma pergunta, se executarmos este comando, Get restore stage Chapter two dot TXT Então, como eu disse, esse comando pegará a cópia do próximo ambiente, que é o ambiente Commit. Mas nosso arquivo do capítulo dois não está disponível na última confirmação porque acabamos de criar nosso arquivo do capítulo dois, e é por isso que nunca confirmamos esse arquivo. Portanto, esse comando removerá nosso arquivo do Capítulo dois da área de preparação Vamos verificar esses status de identificação. Veja, aqui temos dois pontos de interrogação, o que significa que nosso arquivo é rastreado. Então, para resumir rapidamente, se você acidentalmente adicionou alterações na área de teste que não deseja incluir na próxima confirmação, o git restore d stage ajuda você a mover essas alterações de volta para o volta para E com isso, está dando a você a chance de reavaliar ou fazer outras modificações antes de cometê-las. É assim que desmontamos nossos arquivos. 22. Descartando mudanças em arquivos locais: Agora, às vezes fazemos algumas alterações em nosso diretório de trabalho e queremos descartar essas alterações. Em palavras simples, queremos restaurar nossos arquivos locais com os arquivos da área de teste Então, aqui modificamos nosso arquivo do Capítulo Um. Suponha que desejemos desfazer essas modificações para que possamos restaurar esse arquivo local do Capítulo um com nossa área de teste, o arquivo do Capítulo um Para isso, usamos o mesmo comando que é o Git restore. E aqui escrevemos nome do nosso arquivo, que é o ponto THD do capítulo um. Agora, anteriormente, escrevíamos o comando get restore as staged, capítulo um ponto TXT, que tira uma cópia do próximo ambiente, que é commit Porque neste comando, mencionamos stage como nosso ambiente atual usando esse hífen como estágio Agora, se removermos o staged desse comando, você consegue adivinhar qual é o ambiente atual Atualmente, estamos no ambiente de trabalho. Esse comando será copiado do próximo ambiente, e qual é o próximo ambiente? Ele será copiado do ambiente de teste. Também podemos escrever esse comando assim. Obtenha e restaure vários arquivos. Também podemos restaurar todos os arquivos com ponto final. Nosso arquivo é restaurado da área de armazenamento. Podemos verificar isso pelo status do Git. Veja, aqui temos apenas o arquivo do capítulo dois. Mas por que o Git não restaura esse arquivo? Simplesmente porque o Git não tem sua cópia anterior na área de preparação O Git deixa tudo como está. Agora você pode se perguntar: como podemos remover todos os arquivos não rastreados? Para isso, temos que digitar o comando gate clean. Veja, aqui temos um erro. Está nos dizendo a força necessária, para que possamos escrever Gate Cleang para obter ajuda rápida Aqui, podemos ver que, para forçar a remoção, temos que usar F e podemos limpar todo o diretório. Nós também usamos. Escrevemos gate clean f, D. Certifique-se, por meio desse comando todos os arquivos não configurados sejam removidos de nossa área de trabalho e que não possamos restaurá-los Portanto, verifique quais pilhas você está limpando. Agora, vamos verificar o status. Veja, aqui não temos nada, que significa que todos os arquivos são restaurados. 23. Restaurando para uma versão anterior: Agora sabemos que, uma vez que ele começa a rastrear qualquer arquivo, ele armazena todas as versões desse arquivo no histórico. Portanto, se por engano errarmos com nosso arquivo e também o confirmarmos , podemos restaurar nosso arquivo a partir do histórico do git Então, para demonstrar que, primeiro, removemos nosso arquivo do Capítulo um e, em seguida, restauraremos esse arquivo do repositório Git Então, você se lembra de qual comando usamos para remover arquivo do diretório de trabalho e também da área de teste Certo, usamos Git RM, capítulo um ponto Vamos verificar nosso status. Veja aqui na área de preparação, excluímos o arquivo do Capítulo um Agora, vamos confirmar essas mudanças. Então, exclua o arquivo do capítulo um para restauração. Vamos também verificar isso no código VS. Veja, nosso arquivo do Capítulo um foi excluído. Agora, suponha que queremos recuperar esse arquivo. Então, vamos restaurar esse arquivo do repositório Git ou do histórico do Git Vamos conferir nosso histórico com o Gitlog em uma linha. Aqui, queremos restaurar nosso arquivo do Capítulo 1 da penúltima confirmação, o que fizemos. Então, para isso, escrevemos git restore H para obter ajuda rápida. Aqui podemos ver que, após a restauração, podemos adicionar várias opções. E depois disso, temos que mencionar nossa fonte. Fonte basicamente significa confirmar e, depois disso, temos que mencionar o caminho do nosso arquivo. Agora, deixe-me verificar novamente o histórico, o Git registra uma linha Agora podemos escrever o Git, fonte restaurada é igual a aqui em que escrevemos nosso ID de confirmação a partir do qual queremos Escrevemos aqui esse ID de confirmação. Se quisermos restaurar o arquivo de outro histórico de confirmação, precisamos escrever esse ID de confirmação e, depois disso, escrevemos nosso nome de arquivo, capítulo um ponto Agora vamos verificar o status. Veja, aqui obtemos um arquivo não rastreado e se o verificarmos no código VS, veja, aqui obtemos novamente nosso arquivo do Capítulo um É assim que restauramos o arquivo do histórico de confirmações. 24. Operações básicas de Git no VS Code: Então, até agora, nesta seção, realizamos cada tarefa com uma linha de comando e espero que isso esclareça suas dúvidas sobre as operações básicas do Git Agora, em nosso código VS, também podemos realizar algumas operações básicas para o Git Então, aqui vamos ao painel de controle de origem e aqui temos esse tipo de interface. Nessa lista de mudanças, obtemos a lista de alterações. Aqui, obtemos os mesmos resultados que obtemos do comando git status Aqui temos uma alteração, que está neste arquivo do Capítulo 1. Se clicarmos nesse arquivo, aqui podemos comparar nosso código atual com o código anterior. Além disso, podemos ver aqui que esse arquivo é um novo arquivo não rastreado. Agora, para preparar esse arquivo, podemos fazer isso com muita facilidade. Só precisamos clicar nesse botão de adição. Veja, aqui temos mudanças de estágio. Também podemos remover esse arquivo com muita facilidade. Basta clicar nesse botão de menos. Agora temos mudanças locais em nosso diretório de trabalho. Vamos organizar essas mudanças. Agora você pode perguntar: podemos nos comprometer a partir do código VS? E a resposta é sim. Então, aqui escrevemos nossa mensagem de confirmação. Vamos adicionar novamente o arquivo do capítulo um do código VS. Agora, vamos clicar nesse Commit e confirmamos esse código com sucesso . Agora deixe-me te mostrar algo muito legal. Vamos ao painel do explorador e, a partir desta parte inferior, temos a linha do tempo Deixe-me ampliar um pouco. Veja aqui o histórico do nosso arquivo aberto atual. Aqui temos todas as alterações que fizemos em nosso código. Se quisermos ver o histórico do kit , usamos aqui essa opção de filtro. Basta remover a verificação do histórico local e aqui obtemos o histórico desse arquivo atualmente aberto, que é o Capítulo um. Podemos visualizá-lo clicando nele. É assim que podemos usar nosso código VS para operações simples. Agora você pode perguntar: por que não mostro essa maneira de fazer operações básicas? Por que eu ensino linha de comando? Imagine se eu lhe mostrar diretamente esta lição sem explicar todos os comandos anteriores, você definitivamente ficará muito confuso e nunca entenderá o básico do git É por isso que eu primeiro ensino a linha de comando. Agora você definitivamente sabe o que está fazendo no painel de controle de origem. 25. Introdução ao Github Desktop: Agora, deixe-me mostrar a interface gráfica do usuário do uso do Git, que é o Github Essa é uma das melhores e mais fáceis ferramentas de GI para iniciantes para usar o Git Outra ferramenta popular é o Git Kraken, mas é pouco complexa Então, neste curso, aprenderemos o desktop Github, que é amigável para iniciantes e também mostrarei o Git Kraken, que é amigável para iniciantes, e também mostrarei o Git Kraken, que é minha recomendação. Então acesse desktop.github.com, baixe o aplicativo Github Dktop e baixe o aplicativo Github Veja como fica quando abrimos este aplicativo pela primeira vez. Ele está pedindo para fazer login com a conta do Github ou, se você não tiver uma conta no Gitub, poderá criar uma nova conta gratuitamente Eu já tenho uma conta no Github, então eu faço login rapidamente com ela Aqui está pedindo meu nome e e-mail. Certifique-se de verificar esses detalhes. Veja aqui eu também posso alterar meu e-mail e confirmar. Agora, aqui, podemos criar um novo repositório Git e também podemos abrir o repositório Git e também podemos clonar o repositório existente Por enquanto, não se preocupe com a clonagem. Veremos isso na próxima seção. Então, aqui abrimos o repositório Git. Vamos até a pasta do projeto e selecionamos nosso projeto de acompanhamento de tarefas. Veja, aqui temos esse tipo de interface. Se mudarmos alguma coisa em nosso arquivo, vamos adicionar algum texto. Estou escrevendo este capítulo um para introdução. E salve as alterações. Agora, se alterarmos alguma coisa em nosso arquivo em nosso aplicativo de desktop Github, aqui obteremos essas alterações A partir desse ícone de configuração, podemos selecionar o tipo de divisão. Agora, aqui está uma coisa sobre esse aplicativo. Este aplicativo confirmará diretamente nosso código. Se não quisermos confirmar esse arquivo , podemos desmarcar esse arquivo dessa lista Esta lista é uma área de espera. Ok. Agora vamos ver como enviar nosso código para o Git Então, aqui escrevemos nossa descrição de classificação. Você pode ver que, por padrão, está mostrando a mensagem Commit. Podemos escrever primeiro capítulo de atualização para experimentar o desktop do Github E se quisermos escrever uma descrição errada , também podemos escrevê-la aqui. E depois disso, para amit, simplesmente clicamos neste Kammit em nossa filial, que é master. E está feito. Confirmamos nosso código com sucesso. Agora também podemos ver a história de nossas amidas nesta guia Aqui, temos a lista de todas as nossas amidas. Ao selecionar cada meio, podemos ver o conteúdo do arquivo. Assim, você pode ver que o aplicativo de desktop iTu torna o Git tão simples Se você gosta de usar a linha de comando ou o código VS, ou gosta do iTube desktop, está tudo bem Mas, como você pode ver com a linha de comando, podemos controlar mais no Git Podemos realizar várias tarefas por meio de comandos do kit. Honestamente, gosto de usar comandos de kit e código VS, mas a escolha é sua. Você pode escolher uma ferramenta na qual se sinta confiante. Depende totalmente de você. 26. Introdução ao GitKraken: Então, na lição anterior, vemos nossa primeira ferramenta de GI, o GitHub Desktop Temos outra ferramenta que é o kit Kraken, que é um pouco complexa, mas depois de entender e se familiarizar com o kit, você usará mais essa ferramenta Além disso, o Kit Kraken tem mais recursos do que o aplicativo de desktop GitHub. Pessoalmente, gosto de usar o Kit Kraken. Você verá o motivo nas próximas seções. Vamos também instalar o TKracon em nosso sistema. Acesse kitcracon.com e aqui temos um Basta clicar nele e ele iniciará o download. Depois de concluir o download, abrimos uma configuração e podemos instalar facilmente o Git Kraken Agora, quando abrimos o Git Kraken pela primeira vez, aqui temos a opção de abrir um repositório e podemos entrar usando Por enquanto, vamos abrir um repositório. Veja, ele criou automaticamente os detalhes da minha conta Git porque acabei entrar na aula anterior do Github para desktop Então eu posso filmar isso. Aqui temos esse tipo de interface. Podemos abrir o repositório ou clonar o repositório da Internet ou criar um novo Atualmente, queremos abrir o repositório a partir do local, então vamos para o repositório aberto e abrimos nosso projeto atual Veja que é a aparência do nosso repositório. Isso é um pouco complexo para iniciantes porque é muito confuso Sinto o mesmo quando uso o Git kraken pela primeira vez. Mas confie em mim, à medida que nos familiarizamos com o Git, tudo isso se torna muito fácil Aqui estão todos os cometas e podemos ver mais detalhes sobre esse Camt selecionando-os e, no lado direito, obtemos os Veja aqui que obtemos o ID do commit, a mensagem do commit. Depois disso, obtemos detalhes sobre o autor que confirmou essa data e hora e, abaixo disso, obtemos uma lista dos arquivos que excluímos, adicionamos ou modificamos. Basicamente, recebemos as alterações que fizemos neste commit. Aqui, podemos encurtar esses arquivos e também podemos ver os arquivos na estrutura de pastas em árvore. Quando clicamos nesse arquivo, veja, aqui obtemos o arquivo e podemos ver esse arquivo no modo dividido usando este ícone. Por enquanto, isso é tudo , Kraken. Não se preocupe. Veremos o Git Kraken com mais detalhes nas próximas seções Nos vemos na próxima seção. 27. Seção 03 Assistindo ao histórico do código: Bem-vindo à terceira seção do curso definitivo de TI. Nesta seção, veremos como podemos navegar em nosso histórico do Cami com mais detalhes Primeiro, veremos como podemos ver todos os commits, filtrar os commits por nomes de autores, datas e mensagem de confirmação Além disso, veremos como podemos definir comandos de atalho para comandos longos seguir, veremos amidas específicas, compararemos duas amidas, retornaremos à confirmação específica detectaremos erros cometidos, culpas, atribuiremos etiqueta ao gummit Eu sei que você está animado, então vamos começar esta seção. 28. Clonando um projeto local: Agora, para navegar pelo histórico, precisamos de um projeto no qual tenhamos poucos commits Então, abaixo deste vídeo, você obtém a pasta de recursos e, nessa pasta, adicionei o projeto Task Track que criei em SDML e CSS Deixe-me mostrar como você pode clonar qualquer projeto Git existente em sua máquina Então, troque a pasta de recursos, e aqui temos o curso Task track Zip Podemos descompactar isso, podemos simplesmente copiar essa pasta daqui e colá-la na pasta do nosso projeto Agora podemos começar a usar esse projeto. Simples assim. 29. Explorando o comando Log em detalhes: Primeiro de tudo, vamos abrir nosso projeto no Git Bash. Na seção anterior que vimos para observar o histórico do nosso projeto Git, usamos o comando Git clock Esse comando nos fornecerá todos os detalhes do commit sobre cada commit, como o Commit tem detalhes do autor, data e hora e mensagem do commit. Além disso, colocamos esses commits em ordem, o que significa que primeiro recebemos o último commit e, no final, recebemos nosso primeiro commit Temos mais de uma página, então podemos pressionar espaço ou mover para cima e para baixo usando as teclas de seta. Para sair desse comando, pressionamos Q. Agora, você se lembra por qual comando obtemos esse log com menos detalhes Certo, podemos escrever aqui Git log dash uma linha. Veja aqui que recebemos apenas algumas mensagens e confirmações. Já vimos esses dois comandos. Agora vamos ver esse comando de log em mais detalhes. E se quisermos ver os arquivos mudarem em cada comando? Por exemplo, no segundo comando, quais arquivos são modificados ou o que mudamos no último comando? Para isso, precisamos simplesmente escrever datat no final do nosso comando de log Isso significa estatísticas. Veja, aqui alteramos um arquivo e alteramos esse nome aqui. Depois disso, podemos ver 16 inserções. Da mesma forma, temos esses detalhes para cada cometa. Agora, se você se confundir com muitos detalhes, também poderá fazer isso. Adicione aqui uma linha e veja aqui que temos um pouco menos de detalhes sobre o Cometa. Aqui, obtemos apenas quais arquivos são alterados e o número de linhas que alteramos. Mas e se precisarmos ver qual linha adicionamos, removemos ou atualizamos? Não se preocupe, é muito simples. Escrevemos portão, registro, uma linha, despacho. Veja aqui que obtemos as linhas em verde, que adicionamos no arquivo. E se removermos algo desse arquivo , obteremos essas linhas em vermelho. Com esses comandos, podemos ver o que aconteceu em nosso projeto muito rapidamente. Agora, para parar com isso, temos que pressionar o espaço várias vezes e, quando chegarmos, pressionamos Q. 30. Filtrando o histórico: Agora vamos ver como podemos filtrar nosso histórico de confirmações e obter apenas os detalhes específicos que queremos ver. É o mesmo que filtramos produtos na Amazon. Além disso, também é super divertido de fazer. Deixe-me te mostrar. Então, primeiro, vemos como podemos filtrar nossos amites usando o nome do autor Então aqui escrevemos gate, log, uma linha, autor é igual a aqui escrevemos o nome do autor Se o nome do autor tiver espaço em seu nome, você deverá colocar esse nome nos códigos duplos. Caso contrário, fica confuso. Aqui, o nome desse autor é tão sensível que você precisa escrever exatamente o mesmo nome. E se você quiser ignorar o sensível , no final, basta escrever I e obter ignorar o sensível. Veja aqui que obtemos gametas feitos com o nome de Mt Patel. Como podemos filtrar mais esses ácaros? Certo, podemos filtrar amidas usando tâmaras. Então, log do Git, traço uma linha, traço B quatro é igual a aqui, temos que escrever nossa data 2024, nosso mês de 01 a 30. Veja, aqui temos todas as amidas antes dessa data. Agora, às vezes, quando trabalhamos em grandes projetos, gostamos de ver Camids se comprometendo após uma data específica Então, temos aqui depois, e aqui passamos nossa data no mesmo formato. Também podemos passar sequências como ontem, dois dias atrás, uma semana atrás, um ano atrás, etc Isso é muito útil. Eu uso muito isso porque tiro um ou dois dias de licença. Agora, às vezes, queremos filtrar nossa mensagem de confirmação. Por exemplo, somente aquelas confirmações, que têm a palavra tarefa na mensagem de confirmação Escrevemos, registramos, traçamos uma linha, dash grab é igual a em códigos duplos, Isso também diferencia maiúsculas de minúsculas, portanto, certifique-se de escrever a palavra correta. Veja, aqui obtemos kmtes qual mensagem de confirmação tem essa palavra-tarefa, e para ignorar a distinção entre maiúsculas e minúsculas, o que adicionaremos write, adicionamos aqui I. C, aqui obtemos kmtes que tem a palavra tarefa na Agora, às vezes, queremos encontrar um commit específico que adicione ou remova a função ou variável. Por exemplo, estamos trabalhando no projeto Todos, queremos saber quando adicionamos função Adicionar todos ou quando a removemos. Então, podemos fazer algo assim. Registro do Git, traço de uma linha, maiúsculas aqui em códigos duplos, temos que escrever o nome da nossa função Atualmente, neste projeto, não temos essa função. Então eu procuro aqui. Veja, aqui temos os commits Agora imagine que às vezes queremos ver apenas os últimos três cometas ou cinco cometas. Então, podemos escrever git log, traçar uma linha, cinco Veja, aqui temos os últimos cinco cometas. Além disso, às vezes precisamos ver o histórico de um arquivo específico. Por exemplo, queremos ver o ponto de índice STMLFlehtory, quando esse arquivo Então, podemos fazer algo assim. Registro do Git, traça uma linha. Index dot html, e veja aqui que podemos ver a história. Agora, se o nome do seu arquivo já estiver registrado na biblioteca Git, como seu registro de arquivos, aqui , você pode separar esse comando e o nome do arquivo usando Veja, aqui temos o mesmo resultado. Agora, deixe-me te fazer uma pergunta. E se, nesse comando, quisermos ver as alterações dentro desse arquivo? Certo. Temos que escrever a página com hífen, mas temos que escrever a página antes desse traço duplo porque esse traço duplo separa o comando do nome do arquivo e veja aqui 31. Definindo aliases para comandos: Agora, às vezes temos que executar vários comandos do Git que usamos com muita frequência, mas eles são um pouco longos ou difíceis de lembrar Podemos definir um atalho para esses comandos. Por exemplo, frequentemente executamos esse comando de uma linha do Git log dash Vamos definir um atalho ou, em termos do git, definir um Lias.ellas Escrevemos Git config dash global Alias, ponto final. Aqui, temos que escrever nosso nome de atalho para esse comando Então, escrevemos log por log. Certifique-se de usar nomes significativos porque, no final do dia, você precisa se lembrar dos nomes dos atalhos e, depois disso, temos que escrever nosso comando original, que é log one line Aqui, temos que envolver nosso comando com códigos duplos porque temos espaço entre eles e pressionar Enter. Agora, vamos verificar se a configuramos com sucesso ou não. Então, escrevemos configurações globais E, e ele abrirá nosso arquivo de configuração em nosso editor de código padrão Veja, no final, obtemos nosso log de Alias para registrar uma linha Se quiser atualizar ou remover qualquer coisa , você pode fazer isso aqui. Por enquanto, não queremos mudar nada, então vamos fechar esse arquivo. Agora, vamos usar nosso alias. Escreva t lg e veja aqui a saída do comando, então é assim que podemos definir como nossos atalhos para economizar tempo e memória, porque não precisamos nos lembrar de um comando longo inteiro Agora, no restante deste curso, eu não uso esse alias porque se alguém entrar no meio deste curso , não entenderá como estou usando o alias Mas você definitivamente pode usar isso para sua prática. Depende totalmente de você. 32. Ver Commit específico em detalhes: Até agora, vimos como podemos ver todos os commits. Mas às vezes queremos ver detalhes específicos, como o commit específico que o Bits Commit tem. Para isso, podemos escrever Git, show e aqui escrevemos nossa referência de commit Veja aqui os detalhes sobre esse commit específico. Aqui podemos ver que temos apenas um arquivo alterado e, na parte inferior, temos as alterações. Agora, se quisermos obter a última confirmação recente, podemos escrever aqui, veja como chegar com todas as letras maiúsculas. Se quisermos ir mais para baixo na lista de confirmações sem escrever a confirmação, podemos escrever aqui até e escrever aqui o número, digamos dois. Então, primeiro, o Git encontre a cabeça e, em seguida, desça duas etapas e forneça detalhes sobre esse commit Você pode ver que é muito fácil e simples. Agora, se quisermos ver o nome do arquivo que foi alterado em nosso commit específico, então aqui temos que escrever Git, show, head till two, name only Veja, aqui temos apenas um arquivo que muda neste commit. Agora deixe-me te dar mais uma situação. E se quisermos ver o conteúdo completo do arquivo específico em um commit específico. Então, obtemos nosso comando anterior e simplesmente adicionamos aqui a coluna. E aqui escrevemos nosso caminho de arquivo como file dot TXT, ou se tivermos pasta , podemos escrever Css detyle dot css Veja aqui que obtemos o conteúdo completo do arquivo específico em nosso último terceiro comando. É assim que podemos ver o commit específico com mais detalhes. Agora, na próxima lição, veremos como podemos comparar os comandos. 33. Como comparar duas confirmações: Então, quando precisamos comparar A dois commits para ver o que foi adicionado, removido ou alterado em nosso código Então, para isso, usaremos o comando Git di. Esse comando nos dirá a diferença entre nosso diretório de trabalho e o último commit. Atualmente, não temos nenhuma diferença. É por isso que não recebemos nada. Aqui, também podemos comparar dois commits específicos. Digamos que vá até duas cabeças espaciais. Aqui nos dois lugares, também podemos adicionar uma referência de confirmação. Veja, ele tem vários arquivos e várias alterações. Agora, se quisermos ver apenas uma alteração de arquivo específica entre esses commits , o que faremos? Simplesmente, no final desse comando, adicionamos nosso nome de arquivo, estilo CSS dot Agora, na próxima lição, veremos como podemos restaurar nosso código para o commit específico? 34. Retornando para uma versão específica: Agora, às vezes queremos restaurar nosso código para um dos mit específicos. Por exemplo, essa omissão. Queremos fazer do nosso código exatamente o que cometemos nessa omissão Então, escrevemos o Git, damos uma olhada e aqui adicionamos nossa referência de omissão Veja, aqui mudamos para este met. Mas aqui também recebemos esse aviso, que está nos alertando sobre o estado principal separado Agora, muitos desenvolvedores confundem muito sobre o estado, mas isso não é muito difícil. Deixe-me explicar para você. Aqui temos nossa estrutura de compromisso. Esse é o número de cometas. Este é o primeiro comentário e, à direita, nos encontramos pela última vez Aqui podemos ver que todos esses commits estão vinculados ao commit anterior Agora, como podemos ver em nosso Git Bash, atualmente, estamos em nossa ramificação master Branch é o tópico pouco avançado do git. Veremos isso na próxima seção. Por enquanto, entenda que a ramificação é como uma linha que os desenvolvedores criam para o trabalho de um projeto individual. exemplo, se o gerente permitir que você trabalhe em um formulário de login, como desenvolvedor, você cria uma nova ramificação para trabalhar no formulário de login. Master ou main é uma ramificação padrão no git. Aqui, esse mestre é uma referência que representa nosso último kmt Agora, toda vez que confirmamos um novo código, esse mestre passa para o último kat Agora, como sabemos no Git, podemos criar várias ramificações Nesse caso, como o git sabe atualmente em qual ramificação estamos trabalhando Para resolver isso, temos outra referência chamada head. Head aponta a filial atual na qual estamos trabalhando. Já vimos isso antes. Agora, à medida que adicionamos novos commits, esse chefe e mestre também avançarão com nosso último item. Agora, quando verificamos o commit específico , nossa referência principal passa para esse commit. E esse é o estado principal independente. Idealmente, quando estamos no estado principal independente, nesse momento, não devemos confirmar um novo código lá Se criarmos um novo commit , esse met será adicionado aqui. Agora, em algum momento, quando movemos nossa cabeça para o mestre, esse cometa não pode ser acessado por nenhum outro cometa O Git declara esse commit como morto e, após algum tempo, ele removerá automaticamente esse commit de seu registro Portanto, é melhor não confirmar o código quando estamos no estado principal separado Sempre podemos examinar nosso código e fazer experiências com nosso código. Agora, como podemos ver aqui, nosso passe Git mudou. Anteriormente, chegamos aqui, mestre. Mas quando verificamos o comando específico, aqui obtemos o hash de confirmação do nosso commit de checkout. Agora, no ponto atual, se registrarmos todos os nossos comandos usando o Git log one line, aqui, obteremos apenas cometas que foram confirmados antes desse cometa específico Outros cometas são invisíveis neste momento. Não se preocupe, esses outros cometas não foram excluídos. É simplesmente invisível. Além disso, nossa referência principal está aqui. Agora, para ver esses cometas invisíveis, temos que adicionar aqui mais uma variável, que é tudo Veja aqui que obtemos todos os nossos cometas e podemos ver nossa referência principal está aqui e nossa referência principal está aqui Agora, para voltar à referência principal ou principal, podemos escrever aqui Gate, checkout master, e ver, passamos para master e vemos nossa cabeça apontar para master E agora temos todos os comads. Dessa forma, podemos ver nosso código anterior em nosso editor de código ou no explorador de arquivos. E é por isso que o comando de checkout é importante. 35. Detectando o commit com bugs do Git Bisect: Agora imagine se algo acontecer em nosso código e obtivermos nnn Berg em nosso aplicativo , como podemos identificar em qual comando o bug Uma solução é que podemos verificar todos esses comandos um por um usando o comando checkout, mas isso levará muito tempo No git, temos um comando para identificar rapidamente o comando bug, que é usando o Git by set Para iniciar esse processo, temos que escrever porta por conjunto, iniciar e pressionar Enter. Aqui podemos ver que nosso Gitbsh está no modo de bisseção. Agora, depois de iniciar o processo de bisecção, temos que primeiro marcar nosso commit atual como bad kommt Se você quiser saber qual é o ácaro ativo atual , podemos ver isso aqui, que é nosso commit principal. Aqui estamos marcando isso como um casaco ruim porque encontramos um inseto nesse casaco. Tem uma barra de bissecções. Além disso, se você quiser marcar outro met como um kit ruim , no final, temos que escrever sua referência de confirmação. Eu sei que isso é um pouco confuso, mas em apenas um minuto, você entenderá isso Agora, depois disso, temos que contar a marcha, que é a última boa reunião que conhecemos Por exemplo, até que isso aconteça, sabemos que nosso aplicativo não tem nenhum bug. Então temos que fazer com que isso seja o mais bom em. Então escrevemos gate, dividimos ao meio, e aqui inserimos nossa referência do Comitê Agora vamos simplesmente registrar nossos cometas, veja, agora nossa cabeça se move para a metade de nossos cometas Agora, aqui está a parte lógica do comando bisec. Imagine que temos esses dez cometas. Marcamos nosso último cometa como o cometa ruim, e nosso primeiro cometa é o cometa No momento em que definimos nosso primeiro objetivo como bom, a cabeça do KumTo, passe para o ponto médio entre o bem e o mal bom, a cabeça do KumTo, passe para o ponto médio entre o bem e Agora, como estamos focados nisso em, nosso código de trabalho atual será substituído por esse código amet Podemos verificar nossa inscrição aqui em. Se tivermos um inseto neste casaco, então vamos marcar isso como ruim. Se não tivermos um bug nesse anúncio , marcaremos essa data como um bom kamte. Por exemplo, descobrimos que esse amet não tem problema. Então, vamos marcar esse encontro como bom usando o Git BSc good. Agora, ao marcarmos essa taxa como boa, nossa cabeça se move para o ponto médio entre nosso kmt ruim e nosso kat bom Agora, verificamos novamente nosso código. Se for bom, então o marcamos como bom. E se acharmos esse kamete tão ruim, então o marcamos como um cometa ruim Esse processo continuará a restringir a lista e, em seguida, obteremos o cometa que causou a explosão. Essa é a ideia geral do comando bisec. Então, em nosso commit, podemos verificar nosso código no código Vas e ver se ele tem BG ou não. Imagine que descobrimos que esse commit tem um bug. Então aqui marcamos “ get by sec bad”. Agora, novamente, vamos verificar nossa lista, ver como é movido para esse commit. Verificamos novamente nosso código e imaginamos que esse commit não tem problema. Então, faremos com que seja bom usando o Git Biseccd. Veja, aqui temos esse commit como aquele que adicionou o burg em nosso aplicativo. Então é assim que o comando bisec funciona. Pode parecer um pouco confuso, mas se você usar esse comando uma vez, depois disso, você o entenderá facilmente Agora, aqui podemos ver que ainda estamos no modo de corte ao meio. Para sair desse modo, precisamos escrever get bisect reset e ver que estamos de volta ao nosso comando mestre É assim que podemos identificar bugs nos medidores sem verificar todos os medidores na linha 36. Obtendo a lista de contribuidores: Agora, se às vezes quisermos saber quantos commits acontecem pelos usuários para saber a contribuição Então, para isso, escrevemos o log curto do Git. Veja, aqui temos nome do usuário e o número de commits desse usuário Além disso, obtemos o resumo das mensagens de confirmação. Aqui neste projeto, eu sou o único colaborador É por isso que está mostrando apenas meu nome. Agora podemos até mesmo modificar esse comando usando mais opções. Aqui, escrevemos um pequeno registro, H para ajuda rápida. E veja aqui que temos todas as outras opções. Por exemplo, podemos escrever N ou hífen numerados para encurtar a saída pelo número de confirmações feitas por cada saída pelo número de confirmações feitas por Agora, se tivermos uma longa lista de commits, então, para C, cada colaborador, temos que rolar Depois desse N, podemos escrever traço para ignorar a mensagem resumida de confirmação Veja aqui que obtemos apenas o número de vírgulas e o nome de usuário. Agora, na próxima lição, veremos o histórico do arquivo. 37. Navegando pelo histórico do arquivo: Agora, já vimos esse comando antes. Estou apenas adicionando isso aqui porque faz parte da navegação na seção de histórico. Então, como sabemos, para observar o histórico, podemos escrevê-lo, registrá-lo e, para observar o histórico de um determinado arquivo, podemos escrever o nome do arquivo que é HTML com ponto de índice. Veja aqui a lista de códigos nos quais esse arquivo foi alterado Se quisermos restringir essa lista , podemos usar aqui a variável traço de uma linha Veja, agora está legível. Agora, e se quisermos ver as mudanças acontecerem nesse arquivo? Podemos usar aqui os dados para obter a estatística, ou podemos dizer o número de alterações nesse Veja, na primeira confirmação, temos 150 alterações. Da mesma forma, temos 35 alterações aqui nas quais 32 inserções e três exclusões Agora, se quisermos ver as mudanças reais no arquivo , o que faremos no lugar desse ds dat é escrever dispatch Você pode ver que os comandos do Git não são difíceis. É só uma questão de prática, e eu confio em você. Depois de praticar esse comando git em um projeto, você pode usá-los em qualquer outro projeto sem se preocupar 38. Veja o autor de cada linha [Git Blame]: Agora, às vezes, em nosso arquivo de projeto, queremos saber quem é o autor de qualquer linha específica. Isso acontece no meu projeto, um novo desenvolvedor se junta à minha equipe e ele escreve um código muito ruim. Se eu perguntar a alguém que escreve esse código , ninguém responderá, e eu já sei quem escreve esse código. Por isso, sempre peço ao desenvolvedor que verifique quem escreve esse código. Eu não estava tirando sarro desse desenvolvedor no começo, estamos todos nesse nível. Não há nada de errado nisso. Ninguém se torna perfeito no primeiro dia de programação. É uma viagem que leva muito tempo. Voltando ao nosso exemplo do Git, se quisermos saber o autor de uma linha específica , podemos escrever git blame e aqui escrevemos o nome ou caminho do arquivo Veja, aqui obtemos todo o conteúdo do arquivo linha por linha com os detalhes. Aqui, primeiro vamos confirmar a referência na qual essa linha retorna. Em seguida, obtemos o nome do autor e também a data e a hora Agora, se às vezes nosso arquivo tem muitas linhas e queremos saber apenas uma linha específica, podemos escrever L aqui e depois escrever o número da linha, o final do número da linha. Digamos que queremos ver apenas três e quatro. Então aqui escrevemos 34. Se quisermos ver as linhas três, quatro e cinco, escrevemos 35. Veja aqui que temos apenas três, quatro e quinta linha. Para que você possa usar o comando blame para conhecer o autor de cada linha. Agora, na próxima lição, veremos como podemos atribuir uma tag ao commit. 39. Marcando compromissos com tags: Agora, imagine que atualmente esse auxílio esteja pronto para ser lançado na produção, ou queremos marcar esse código de confirmação como a versão 1.0. Mas eu já dou isso na versão 1.0. Eu tenho que dar aqui a versão 1.0 0.1. Portanto, dar um nome de versão ao medicamento é chamado de atribuição de tags no Git Vamos marcar esse amet como a versão 1.0 0.1. Aqui escrevemos git tag, versão 1.01. Aqui podemos escrever nossa referência de confirmação e aqui não adicionamos nenhuma referência de confirmação e , por padrão, podemos dar essa tag ao nosso commit atual, que é o commit principal. Agora, se registrarmos nossos commits, veja, aqui obtemos a tag versão 1.01 após essa referência de commit Agora, se quisermos verificar nosso código para esse commit , não precisamos escrever essa referência de commit. Podemos simplesmente usar o Git, confira a versão 1.0 Da mesma forma que usamos esse ID de confirmação, podemos usar essa tag, versão 1.0. Agora, suponha que eu queira ver todas as tags que dei a este projeto. Em seguida, simplesmente escrevemos a tag Git e vemos aqui todas as tags que atribuímos Agora, suponha que adicionemos essa tag misticamente e agora queremos remover essa tag Então, simplesmente escrevemos git tag D, escrevemos o nome da nossa tag, que é a versão 1.01 Agora podemos ver que a tag foi removida da lista. Aqui temos essa tag da versão 1.0, que chamamos de tag leve, o que significa que damos ao nosso meio apenas uma referência como versão 1.0. Agora, no Git, também temos uma tag anotada. Agora você pode perguntar o que são tags anotadas? Portanto, a tag anotada é usada para adicionar mais detalhes, como nome, data e hora do marcador e mensagem Em palavras simples, com tags anotadas, podemos simplesmente adicionar mais detalhes com nossas Aqui está o comando para tags anotadas. Escrevemos a etiqueta de porta A para a versão anotada 1.01 M, que significa mensagem E nos códigos duplos, podemos inserir nossa mensagem como a versão de lançamento 1.01 Saiba que essa mensagem não é muito útil, mas estou apenas mostrando que, se você quiser adicionar uma mensagem com essa tag anotada , você pode fazer isso Agora, se escrevermos essa tag , obteremos duas tags. Se você quiser ver uma mensagem de texto, então temos que escrever a tag Git N. Veja, aqui temos as mensagens da tag Se nossa tag for uma tag leve, receberemos essa mensagem de confirmação como a mensagem da tag. Portanto, não se confunda com isso. Agora, se virmos nossa versão 1.01 com o comando Mostrar versão 1.01 , veja aqui na parte superior, também obteremos os detalhes do marcador, como nome, e-mail, data e hora em que fornecemos essa mensagem de tag e tag É assim que usamos tags para marcar versões. 40. Commit History no Github Desktop: Então, vamos ver a história dos nossos CIDs no aplicativo Github Extra Então, vamos abrir esta seção do projeto no aplicativo Github Extra Vá até o arquivo, adicione o repositório local. E aqui vemos o caminho da nossa pasta. E simplesmente selecione essa pasta. Na lição anterior, vemos como ver as mudanças no aplicativo de desktop Github Agora veremos como navegamos histórico de confirmações usando esse aplicativo. Então, aqui temos uma lista de commits no lado esquerdo e também temos aqui nosso texto e aqui no topo, recebemos a mensagem do Commit, recebemos a mensagem do Commit nome do autor e a referência do Commit Agora, aqui temos a lista de arquivos alterados. Se clicarmos neles, obteremos as alterações aqui. Além disso, podemos alterar nossa visão a partir dessa configuração Agora, podemos ver que temos poucas opções para navegar em nosso histórico de commits. Por exemplo, não podemos filtrar nossos commits, não podemos pesquisar uma função ou variável específica e muitas outras coisas aplicativo de desktop Github tem uma interface de usuário simples, mas não é o melhor para usar o Git Este é um artigo que eu gosto. Nesse artigo, vejo que os desenvolvedores dizem que só gostam do aplicativo de desktop Github quando são iniciantes no Git Mas, à medida que aprendem o Git com mais detalhes, eles realmente não gostam do aplicativo de desktop Github Eu concordo um pouco com isso, mas isso não significa que você precise desinstalar o aplicativo de desktop Github Você pode usar o Github destra Publication se estiver confortável Depende totalmente de você. 41. Como navegar no histórico no VS Code e no GitKraken: Agora vamos ver como podemos navegar pelo histórico usando nosso editor de código VS code favorito. Então, como vimos na seção anterior, aqui podemos ver nossas alterações no código. Mas e se quisermos ver a história de nossos mets e também a lista de cometas Podemos ver isso no código do VS, mas podemos ver isso usando uma extensão chamada Gitans Essa é uma das extensões Git mais populares no VSCode, e a parte engraçada é que essa extensão é do Você usa o Git Kraken em vez do Github desktop, então você verá a mesma interface que vemos Veja aqui que temos mais duas opções no lado esquerdo para a lente git Abra este primeiro, deixe-me diminuir um pouco o zoom, fechar isso, também fechar isso. Agora, nisso, temos muitas opções. Veja, primeiro, temos o gráfico Commit. Essa é uma das formas mais populares de visualizar o histórico de omissões. Aqui, podemos ver, obtemos uma lista de nossos commits e aqui também podemos obter o texto que fornecemos aos commits Em seguida, temos a mensagem de confirmação, o nome do autor, as alterações nos arquivos, a hora e a referência da confirmação. Na parte superior, temos também a barra de pesquisa para pesquisar os cometas. Se pesquisarmos algo aqui , ele destacará apenas os anúncios cuja mensagem de confirmação tem essa palavra. Agora, para mais filtros de pesquisa, temos uma pequena lista suspensa aqui. Primeiro, recebemos minhas alterações, que nos mostrarão apenas os cometas que foram cometidos por você Em seguida, temos uma mensagem para pesquisar a mensagem de confirmação. Em seguida, temos o autor pelo qual podemos pesquisar os commits pelo nome do autor Depois disso, temos o commit SHA no qual podemos pesquisar commits por referência de commit Em seguida, também podemos pesquisar um arquivo específico. Por exemplo, escrevemos aqui o ponto de índice HTML. Veja, aqui temos apenas os commits destacados. E por último, temos a mudança pela qual podemos pesquisar funções ou variáveis. Agora, se selecionarmos um comando no lado direito, podemos ver mais detalhes sobre esse commit. Na parte superior, obtemos a referência do commit. Aqui, divulgamos nosso nome, horário e também confirmamos a mensagem. Agora, na parte inferior, temos a seção para o arquivo alterado, e aqui temos o número de arquivos adicionados, que é zero, o número de arquivos alterados, que é um, e o número de arquivos removidos, que é zero. E abaixo disso, obtemos a lista de arquivos que são adicionados, alterados ou removidos. Se selecionarmos esse arquivo , podemos ver a diferença que fazemos nesse arquivo. Muito útil. Agora, depois dos gráficos de confirmação, temos mais opções Mas, como podemos ver, há muitas coisas que não podemos ver aqui, e é por isso que os comandos do Git são essenciais para aprender Depende totalmente de você o que você quer aprender. Na minha humilde opinião, aprender as duas coisas é mais benéfico para você Deixe-me mostrar como podemos navegar pelo histórico usando o aplicativo Git Kraken Abrimos nossa pasta de projetos, que queremos abrir, basta clicar com o botão direito do mouse aqui e abrir com o Git Kraken Aqui está a interface do aplicativo Git Kraken. É muito semelhante à extensão da lente Git. Aqui, obtemos a lista de confirmações que fizemos na parte superior Também temos opções de pesquisa nas quais podemos pesquisar por mensagem de confirmação Aqui também podemos filtrar os commits dos autores. Agora, ao selecionarmos o commit, obtemos os detalhes do commit no lado direito. Aqui, obtemos a referência do Commit, mensagem do commit, o autor, data e a hora e os arquivos modificados. Se selecionarmos Arquivo, obteremos aqui as alterações. Também podemos alterar o tipo de visualização para dividir. No topo, também podemos culpar por ver o autor do commit. No lado direito, também temos uma estrutura de pastas em árvore e também podemos visualizar todos os nossos arquivos de projetos. Assim, você pode ver que, ao usar o aplicativo Kraken, podemos navegar facilmente em nosso histórico Usamos lentes Git, então não temos muito espaço Está muito congestionado. Portanto, use o que quiser , depende totalmente de você. Agora, na próxima seção, veremos o tópico mais importante do git, que são ramificações, até a próxima seção 42. Seção 04 Trabalhando com filiais: Bem-vindo à quarta seção do curso definitivo do Git. Nesta seção, aprenderemos tudo sobre ramificações, como criar ramificações , visualizá-las, compará-las com ramificações, como mesclá-las, resolver conflitos e muito, muito mais coisas Esse é um dos tópicos mais importantes do Git. Eu sei que você está empolgado com isso, então vamos começar esta seção. 43. O que é Branch: Agora, como sabemos, nosso projeto de controle de tarefas é o STMLNCSSPject , que eu criei Agora imagine que estamos adicionando um novo recurso. Por exemplo, o recurso de arrastar e roubar neste projeto. Então, em vez de adicionar esse recurso em nossa ramificação mestre, podemos criar uma nova ramificação. O Git branch é como uma nova linha em nossos mets. Então, como sabemos, quando confirmamos nosso código, forneça Master Pointer para nosso último commit Agora, quando decidimos adicionar um novo recurso em nosso projeto , primeiro criamos uma nova ramificação, digamos, recurso de arrastar e soltar ou recurso DND Agora, essa ramificação tem o mesmo instantâneo do nosso código. Aqui, podemos confirmar nosso novo código de recurso e, quando confirmamos , esse código não afetará nosso código de ramificação principal. Podemos trabalhar em nosso código isoladamente. Agora você pode se perguntar por que precisamos criar ramificações. Podemos até mesmo enviar nosso código para a ramificação master? Não, não podemos fazer isso porque, se escrevermos código para escrever , esse não é o problema. Mas se erramos com nosso código , não queremos armazenar confusos em nosso histórico de códigos Se criarmos uma ramificação e errarmos com nosso código , podemos simplesmente remover essa ramificação completamente e isso não afetará nossa ramificação mestre Essa é a ideia. Agora você pode perguntar: como o Git sabe em qual ramo ou camada estamos trabalhando Para isso, o Git tem outro ponteiro chamado head. Já vimos esse ponteiro. Por padrão, nosso ponteiro principal está com o ponteiro principal ou principal Se você trabalha em outra ramificação , o Git só move o ponteiro principal para essa confirmação da ramificação Então é assim que as ramificações do Git estão funcionando. Para simplificar, lembre-se se você for trabalhar em algo diferente, poderá trabalhar isoladamente criando ramificações. Em grandes empresas, muitas equipes trabalham em filiais diferentes, portanto, seu código não causará problemas com a ramificação master, e obtemos um código estável em nossa história. 44. Criando uma nova filial: Agora, para praticar as ramificações, usaremos nosso projeto anterior, que é o curso Task Track Se você estiver começando com esta seção, poderá obter essa pasta do projeto Task Track nos recursos deste vídeo. Neste projeto, imaginaremos trabalhar no recurso Dragon Drop Para isso, criaremos nossa primeira nova filial. Criar a ramificação no Git é muito simples. Só precisamos escrever o recurso Git branch slash DND, que significa Aqui, você pode usar qualquer nome. Estou usando recursos do DND para esclarecer que estamos trabalhando em outro recurso, não corrigindo os bugs Depende totalmente de você como você quer chamá-lo. Achei esse estilo mais útil, então estou usando isso. Agora, para ver os galhos, podemos escrever, portar, ramificar e dar uma olhada. Aqui, temos apenas duas ramificações com barra DND e nossa ramificação padrão, que é master Atualmente, estamos na ramificação master, e é por isso que recebemos uma estrela antes da ramificação Master. E também podemos ver aqui o nome da filial atual. Agora, para trabalhar na ramificação DND, primeiro precisamos mudar para essa ramificação DND. No início, para mudar de ramificação, precisamos usar o comando Git checkout. Mas como esse comando é um pouco confuso, introduza um novo comando específico para alternar ramificações, que é o Git Aqui escrevemos o nome da nossa ramificação, que é feature slash DND Veja aqui nossa marca mudou Lovely. Agora, vamos abrir esse projeto no código VS usando o ponto final do código. Agora, digamos que prevejamos que adicionamos um recurso de arrastar e desenhar. Para demonstrar, abro essa pasta JS e, nesse script, pontuo o arquivo JS. E na parte superior, adiciono um comando usando Control Slash ou Command Slash, adicionando o recurso de tag e draw Na parte inferior do registro de pontos do console, esse é o recurso de arrastar e soltar. Salve este arquivo e veja aqui que obtemos as modificações. Agora que podemos prever, concluímos aqui nossa implementação do recurso Dragonrop. Podemos adicionar essas alterações à área de teste usando o Git add period Depois disso, o Git comt e o message implementam o recurso dragon drop Veja, aqui temos um arquivo alterado e duas inserções. Agradável. Agora vamos ver os commits. Obtenha o registro, uma linha. C, na parte superior, temos features slash DND commit e nosso headpointer está atualmente na Então, quero esclarecer uma coisa: as alterações que fizemos nessa ramificação só serão visíveis nessa ramificação. Se voltarmos para a ramificação master com o kit switch master, veja, aqui obtemos a versão antiga do nosso código. Agora, se registrarmos nossos commits, aqui não obteremos o recurso slush D and D coat porque esse é um passo à frente de nossa mestra Se você quiser ver todas as ramificações, então temos que escrever aqui, gate, log, d dash, one line, d dash Veja, aqui temos o galho. No futuro, concluiremos com êxito implementação desse recurso e queremos adicionar esse código à nossa ramificação master. Podemos mesclar esse código na ramificação master. Veremos isso nas próximas aulas. Mas depois de mesclar nossa ramificação com a ramificação master, precisamos excluir nossa ramificação Para exclusão, escrevemos a ramificação D do Git, aqui escrevemos o nome da ramificação com as características D e D. Agora, isso nos dará um erro ou podemos dizer um aviso, que indica que essa ramificação não está totalmente mesclada porque não mesclamos essa ramificação com a ramificação master Agora, se você certamente deseja excluir essa ramificação , podemos escrever o mesmo comando com a letra D maiúscula. Atualmente, não estou removendo essa ramificação porque nas próximas aulas mostrarei como trabalhar com a ramificação e mesclá-la Espero que você entenda os galhos. Em palavras simples, get branches ajudam os desenvolvedores a trabalhar isoladamente. 45. Veja as mudanças entre ramos: Agora, às vezes em nosso projeto, não conseguimos realmente lembrar o que mudamos em nossa filial, especialmente quando fazemos uma pausa de dois, três dias. Então, como podemos ver a lista de Komats que executamos após nossa ramificação master Então, para isso, usamos kit, log, master, dot dot. Aqui, escrevemos o nome da nossa ramificação, que é feature slash DND Veja, aqui temos apenas uma , entre as quais fizemos na última lição. Se fizermos mais de um commit , também receberemos todos esses commits aqui. Se quisermos ver apenas a mensagem de confirmação , é claro que podemos usar o traço de uma linha Agora você pode perguntar: e se eu quiser ver as mudanças reais que fizemos entre nosso código principal e o código de ramificação do DND Você se lembra de qual comando usamos para prever a diferença entre dois commits Usamos o comando Diff para isso. Escrevemos Git, Dave, master, dot, dot, que são as barras D e D. Por esse comando, vemos a diferença entre essas Veja, aqui alteramos nosso arquivo JS de um ponto de script, que está na pasta JS e podemos ver essas duas linhas sendo adicionadas. Aqui, eu tenho um pequeno truque de atalho para você. Se estivermos trabalhando em uma dessas ramificações, só poderemos escrever a referência de confirmação ou o nome da outra ramificação. Em palavras simples, aqui estamos atualmente na ramificação master. Podemos simplesmente escrever aqui assim, Kate D, e escrever diretamente o nome da nossa filial com a qual queremos comparar. Destaque as barras D e D. Veja, aqui temos a diferença Agora você pode dizer que essas duas saídas são diferentes e isso é verdade O problema é que aqui estamos comparando a ramificação master com nosso recurso, slash DND branch, e é por isso que inserimos essas duas linhas Agora, no equipamento de atalho, estamos comparando o recurso, slash DND branch com nosso branch master, e é por isso que temos aqui a exclusão de Mas isso não importa porque só queremos ver a diferença. Às vezes, queremos ver apenas os arquivos que foram alterados. Então, para isso, podemos escrever apenas o nome Get did, ou podemos usar n status e escrever nossa ramificação DND de recursos Veja, aqui nós apenas alteramos um arquivo que é script dot JS. Então, se mesclarmos essa ramificação DND com nossa ramificação master , nosso único arquivo será modificado Usamos a opção somente o traço do seu nome e, em seguida, obtemos apenas os nomes dos arquivos Mas, à medida que usamos o status do traço do nome , obtemos os nomes dos arquivos com o status de modificação, inserção ou exclusão Agora, na próxima lição, veremos o sassing git. 46. Mestre o stashing: Agora, antes de começarmos a aprender a esconder, deixe-me te dar uma condição Imagine que você está trabalhando em um projeto importante e está na metade do seu código. Agora, de repente, seu gerente vem até você e pede que você corrija o bug no recurso Dragon Drop agora mesmo. Agora, nessa situação, o que você vai fazer? Uma opção é que você pode confirmar as alterações feitas e, em seguida, trabalhar no recurso Dragon Drop. Mas, como eu disse, você está na metade do seu código. Você não pode confirmar esse código. Parece pouco profissional. Agora, qual é a solução nessa situação? No momento, podemos armazenar nossas alterações atuais no canto do portão e quando terminarmos nossa outra tarefa , podemos voltar para essas alterações. Dessa forma, nosso meio código não ficará vírgulas e também não perderemos nosso meio código Esse processo pelo qual armazenamos nosso meio código no canto é chamado de atsing Sas , o que significa escondê-lo em algum lugar Para mostrar a metade do código, eu adiciono no script dot jslecs Isso é meio código. Eu não quero perder. Salve as alterações e, se verificarmos nosso status atual, aqui, obteremos uma modificação e, se tentarmos mudar para a ramificação DND de recursos , obteremos o erro que diz que suas alterações locais nos seguintes arquivos seriam substituídas pelo Por favor, confirme suas alterações ou organize-as antes de mudar de filiais. Basicamente, está dizendo que, se não confirmarmos ou organizarmos as mudanças e tentarmos mudar para outra ramificação , perderemos essas mudanças. Então, para esconder o código, escrevemos Git push A, e aqui escrevemos nossa mensagem de estresse para Digamos que esteja trabalhando em modificações no design do site. Veja, salvamos o diretório de trabalho e o índice no Master. Agora queremos ver todo o trabalho que fizemos em nosso projeto. Em seguida, escrevemos a lista de estatísticas do Git. Veja, aqui temos o Ss, marque como vermelho no colchete zero na ramificação Master e nossa mensagem SS Agora, aqui está uma coisa. Esse comando git stash push não adicionará arquivos não rastreados nas Por exemplo, aqui na pasta JS, eu crio um novo arquivo chamado tamp dot js E nesse arquivo, eu adiciono arquivo temporário de comando. Guarde isso. E se escrevermos o status do Git, aqui obteremos o arquivo JS temporário como arquivo não Então, se executarmos aqui o Git push, Git não adicionará esse arquivo em nosso estoque Então, para isso, temos que escrever aqui, ou podemos escrever A e, em seguida, para a mensagem escondida Aqui também podemos combiná-los e, em seguida, escrever nossa mensagem escondida, que é adicionar um arquivo temporário. Agora, se executarmos novamente o git stash list , aqui chegaremos ao Veja aqui nossa primeira corrida, vá para a aeração de estatísticas um e nossa última corrida adicionada na aeração de estatísticas zero Aqui, eliminamos com sucesso nossas alterações atuais. Agora podemos mudar para a ramificação DND de recursos usando o switch Git, ramificação de recursos DND Veja, aqui obtemos o nome da ramificação atual e, em nosso editor de código, nosso arquivo de script também é alterado para a versão DND de recursos Lembre-se de que editamos essa linha de console. Agora imagine que concluímos nosso trabalho nessa ramificação, para que possamos alternar novamente para a ramificação master. Agora, queremos obter as alterações que adicionamos ao estoque Agora, antes de adicionar essas mudanças, queremos ver quais são essas mudanças. Então, para ver as mudanças, escrevemos Git show, e aqui escrevemos o nome do nosso estoque, que é iterado entre colchetes Ci Agora, aqui, se você não quiser escrever esse nome estranho , só podemos escrever esse número zero Veja aqui que não obtemos nada porque nessas estatísticas, adicionamos apenas js de pontos temporários não rastreáveis Por padrão, não mostre o arquivo de faixa nesse comando. Então, para ver também UntrackFle, temos que adicionar aqui U. Veja, agora temos o arquivo Temp dot js Se você quiser aplicar essas alterações em nosso diretório de trabalho local , podemos escrever Git apply zero Veja, agora obtemos o arquivo de rastreamento e também podemos verificá-lo em nosso editor de código. Bom. Agora, à medida que aplicamos essas alterações em nosso diretório de trabalho, não precisamos desse zero. Assim, podemos remover o estoque e não queremos reunir muito estoque em nosso projeto É uma prática muito boa remover estoque que não precisamos mais. Podemos escrever Gates drop zero. Agora, se virmos a lista de staches , não obteremos o estoque Agora, vamos simplesmente aplicar esse stash em nosso diretório de trabalho. Escrevemos o Git, aplicamos, e o que escrevemos aqui, escrevemos Escrevemos aqui novamente, zero porque removemos o primeiro zero e marcamos nosso um a zero. Veja, temos duas alterações em nosso projeto, uma no arquivo de script e uma no arquivo de trilha. Vamos remover esse estresse também. Assim, podemos escrevê-lo novamente, zero. Ou também podemos usá-lo de forma clara. Esse comando removerá toda a estase do nosso projeto. Veja, toda a estase acabou agora. 47. Entendendo o Merge no Git: Agora, imagine que terminamos com nosso recurso de arrastar e linha, então queremos mesclar esse código com nossa ramificação master Mas antes de fazer qualquer coisa, primeiro precisamos verificar a ramificação atual. Veja, estamos na filial principal. Então, primeiro, temos que mudar para a ramificação DND de barra de recursos Mas aqui temos algumas mudanças em nosso diretório de trabalho, e é por isso que ele nos convenceu a mudar. Mas aqui não queremos essas mudanças, então podemos mudar com força para nossa ramificação DND de barra de recursos Para isso, temos que escrever gate, switch, four, feature slash DND branch. Verifique seu código antes de executar esse comando em seus projetos, pois você perderá suas alterações permanentemente. Agora, em nosso arquivo scrap dot js aqui no console, escrevo feito com o recurso de arrastar e soltar e também removo esse comando da parte superior, vamos remover esse console Este arquivo e também remova esse arquivo de cães de carimbo. Nós não queremos isso. Agora, de volta ao terminal. Aqui, primeiro organizamos nossas mudanças. E então podemos simplesmente Git Cate M, completar o recurso de arrastar e soltar Bom. Agora, queremos mesclar nossa ramificação DND de recursos com nossa ramificação master Portanto, há dois tipos de mesclagem no Git. O primeiro é rápido para mesclar e o segundo é a fusão de três vias Vamos ver cada tipo de fusão com um exemplo simples. Primeiro, veremos a rapidez de nossa fusão. Então, aqui temos várias amidas e, depois disso, criamos uma nova ramificação chamada característica D&D. Agora, nesta ramificação, criamos vários cometas Agora, nesta fase da ajuda, concluímos nosso recurso e decidimos mesclar nossa ramificação de recursos com a ramificação master Então, nesse momento, podemos mesclar diretamente essas duas ramificações sem nos preocupar com Essa fusão chamamos de guerra rápida contra a fusão. Agora vamos ver a fusão de três vias. Anteriormente, depois de criar a ramificação, não confirmávamos nada em nossa ramificação master. Mas no mundo real, isso aconteceu muito raramente porque, como sabemos, há muitos desenvolvedores trabalhando em um único aplicativo. Há uma possibilidade em que outros desenvolvedores se comprometam na ramificação master. Naquela época, nossas filiais se diversificam. Portanto, temos algumas mudanças na ramificação master que não temos em nossas ramificações S D e D de recursos. Agora, se executarmos o merge aqui, Git não moverá nosso master para a barra de recursos DND commit pois isso removerá as alterações do Então, quando executamos o comando merge aqui, Git cria um novo commit que combina as alterações dessas duas ramificações Agora você pode perguntar por que chamamos essa fusão de mesclagem de três vias , pois ela depende dos três O primeiro é o ponto comum de junção de dois ramos. segunda é a última encontrada na ramificação master , chamada de ponta da ramificação master, e a terceira é a ponta da ramificação DND da barra de recursos O Git olha esses três cometas e mescla nosso código de acordo com esse novo cometa criado pela marcha é Para recapitular, há dois tipos de fusão. primeira é paginar ou mesclar se nossas ramificações não divergirem ou podemos dizer que não adicionamos um novo cometa em nossa ramificação mestre depois de criarmos uma nova ramificação A segunda é a fusão tripla se nossas ramificações forem divergentes ou se pudermos dizer que fizemos uma nova confirmação na ramificação master depois de criarmos a ramificação Agora, nas próximas lições, veremos esses dois se fundirem Não se preocupe, é muito simples. 48. Aplicando a fusão rápida: Agora, vamos ver a rapidez da nossa fusão. Para recapitular rapidamente a fusão, temos um caminho de confirmação linear e o get move diretamente o ponteiro mestre para nossos Vamos ver como podemos fazer isso. Em primeiro lugar, registraremos todos os nossos códigos e, como sabemos, se você quiser ver as ramificações, teremos que usá-los para registrar, traçar uma linha, traçar tudo traçar uma linha, traçar E quando estamos trabalhando com ramificações, podemos escrever aqui a opção de gráfico de traços É altamente recomendável usar essa opção de gráfico , pois ela nos mostrará que temos diversos cometas ou não Além disso, você não precisa escrever esse comando longo toda vez. Você pode usar como para isso. Agora, atualmente, não temos cometas diversos e é por isso que não podemos ver gráficos diversos, mas é assim Agora podemos ver que atualmente estamos na ramificação do recurso DND porque nosso ponteiro principal está Agora, para mesclar essa ramificação DND de recursos em nossa ramificação master, precisamos primeiro mudar para a ramificação master Bom. Agora podemos ver nosso ponteiro principal ser movido para a ramificação master Agora, para mesclar essas ramificações, escrevemos git merge e, em seguida, escrevemos o nome da ramificação, que queremos mesclar Veja, aqui estamos prontos para nossa fusão. Agora podemos ver novamente todos os cometas usando nosso comando anterior Veja aqui que não obtemos novo cometa, basta passar o ponteiro mestre para a ramificação característica SS DND porque temos cometas lineares ou podemos dizer que não temos amidas diversas E se às vezes não quisermos aplicar a mesclagem rápida. Está totalmente bem. No git, também podemos aplicar a mesclagem não rápida, e veremos isso na próxima lição 49. Fusão não rápida: Agora, deixe-me mostrar como podemos evitar a fusão rápida Então, para demonstrar, temos que criar uma nova ramificação e depois mudar para essa ramificação. Então, essas são duas etapas diferentes. Deixe-me mostrar um atalho para fazer essas duas etapas em uma única etapa Então, podemos escrever o interruptor de porta C para criar, aqui escrevemos o nome da nossa ramificação. Digamos que apresenta feedback. Veja, mudamos diretamente para a seção de feedback. Agora, de volta ao código VS, e aqui eu abro o ponto de índice STMLFle Se você quer saber como estou abrindo o arquivo, basta pressionar Control plus P ou Command plus P e escrever o nome do arquivo aqui. Agora, na parte inferior, depois da nossa tag principal, adiciono um comentário para o formulário de feedback. Imagine que adicionamos aqui o formulário de feedback, salvamos as alterações e voltamos ao nosso Git Bash Aqui, primeiro preparamos todas as alterações e, em seguida, confirmamos as alterações como uma mensagem de confirmação feita com o recurso de feedback. Bom. Agora, vamos verificar nosso histórico de comentários. Veja, aqui temos nosso último compromisso. Agora vamos mesclar essa ramificação de feedback com nossa ramificação master por meio de uma fusão não rápida O que faremos antes da fusão voltar para a ramificação master Agora, aqui escrevemos Gate, merge, Ff sem avançar rapidamente e simplesmente escrevemos aqui o nome do nosso branch, que é feature slash feedback Por meio desse comando, estamos dizendo ao Git que, se o avanço rápido for possível nessa mesclagem, ainda não faça isso e crie um novo comando, que combine duas A diferença fácil entre a mesclagem rápida e não rápida é que na mesclagem rápida, git não cria um novo commit, mas na mesclagem sem avanço rápido, o Git cria um novo comando Git Agora, no momento em que clicamos em Enter aqui, Git solicita a mensagem de confirmação de mesclagem Por padrão, recebemos aqui essa mensagem de confirmação gerada pelo git Se quisermos mudar isso , podemos mudá-lo aqui. Salve o arquivo e feche-o. Agora, em nosso terminal, podemos ver a fusão concluída E se virmos o histórico com a opção de gráfico, veja, aqui temos o gráfico dos nossos commits Podemos ver nosso Master Pointer, mas nossa ramificação de feedback de recursos ainda está lá, e o Git criou um commid de mesclagem que combina alterações de feedback de recursos E obtemos esse gráfico porque adicionamos a opção de gráfico em nosso comando log. Agora você pode perguntar qual é a melhor coisa para mesclar? Fusão rápida ou devemos usar não rápida para ou mesclar. Vamos ver os prós e os contras dessa fusão. Em primeiro lugar, quando usamos o fast para a fusão, podemos ver nossa história com muita clareza porque não há divergência nos Mas se usarmos o non fast para mesclar , nosso histórico pode parecer um pouco confuso No momento, podemos ver isso porque temos apenas uma divergência. Mas no mundo real, grandes projetos não têm apenas um ramo. São várias filiais e muitas filiais diversas. É por isso que a fusão não rápida parece um pouco confusa, o que também significa que a fusão rápida tem mais clareza visual e, por outro lado, temos menos clareza visual sobre Agora, outra coisa é que, se usarmos a mesclagem rápida, poderemos pular alguns contextos como quando mudanças específicas Mas se usarmos o non fast para mesclar , não perderemos nenhum contexto Com cada fusão de cometas, temos detalhes sobre quando e onde fazemos Agora, depois disso, no fast per merge, não podemos isolar nosso código de duas ramificações Mas, sem agilizar nossa fusão, podemos isolar nosso código de duas ramificações porque temos gomas de mesclagem separadas Esses são os prós e os contras dessas duas fusões. Na minha opinião, essas duas opções têm prós e contras. Você está trabalhando individualmente e, em seguida, pode selecionar qualquer tipo de mesclagem Depende totalmente de você. Mas muitas vezes sua equipe dirá para você usar a fusão rápida ou não Agora, quando estamos no fluxo de nosso trabalho, podemos esquecer de não usar nenhuma opção de avanço rápido, e sua empresa solicita que você use apenas a opção de avanço não rápido Portanto, a solução dessa situação é que podemos definir opção de avanço não rápido para nosso repositório atual ou também podemos configurá-la para todo o repositório em nosso sistema Para isso, podemos escrevê-lo config, FF, no. Esse comando desativará avanço rápido em nosso repositório atual Além disso, se quisermos desativar o avanço rápido para todos os repositórios , podemos simplesmente adicionar o dads Global 50. Entendendo a fusão de 3 maneiras: Agora vamos ver a fusão de três vias. Como sabemos, se criarmos uma nova ramificação, fizermos uma confirmação nessa ramificação e, em seguida, também confirmarmos em nossa ramificação master, podemos chamar essas duas ramificações ou divergir uma da outra Agora, nessa situação, olhe para as duas pontas desses galhos e também para o cometa comum onde esses dois galhos divergem Ele descobre a melhor maneira de combinar esses dois ramos e aplicar essas mudanças no novo cometa. Para demonstrar isso, criamos novamente uma nova filial. Usando o interruptor de porta C para Create, e então damos nosso nome ao usuário feature slash Register Agora, de volta ao código VS. Aqui na pasta do projeto, criamos uma nova pasta chamada registro de usuário. E dentro dessa pasta, criamos um novo arquivo chamado register form dot SGML E dentro disso, adiciono rapidamente um trecho de HTML e altero o título para o registro como novo usuário Salve esse arquivo e volte para o nosso terminal. Aqui, primeiro preparamos todas as alterações e seguida, também as confirmamos em nossa ramificação de registro de usuários. Bom. Vamos ver nosso histórico usando o log do Git, traço uma linha, traço tudo, gráfico Des dash Veja, aqui temos nossa nova filial. Agora, vamos voltar para a ramificação master. No arquivo script dot js, adicionamos aqui a linha dot log do console e aqui o console aprendendo a fusão de três vias Salve o arquivo e, no Git Bash, primeiro, preparamos nossas alterações e, em seguida, simplesmente confirmamos Git, atualize o arquivo script dot js para mesclagem de três vias. Bom. Agora vamos ver novamente a história. Aqui podemos ver a divergência em nossos galhos. Se estivermos trabalhando nessa ramificação , podemos ir diretamente aqui na ramificação master. Isso é chamado de ramificação divergente. Agora vamos mesclar esses dois ramos. Aqui está uma boa notícia para você. Não temos um comando separado para a fusão de três vias. É o mesmo comando que usamos para a fusão rápida Se tivermos ramificações divergentes, o que significa que entramos na ramificação master depois de criarmos uma nova ramificação, aplique automaticamente a mesclagem tridirecional Qual é o comando para mesclar? Certo, git merge, e aqui adicionamos o usuário de barra de recursos e Ele completará automaticamente o comando. Aqui, peça a mensagem de confirmação de mesclagem. Deixo como está, fecho esse arquivo e vejo aqui nossas ramificações serem mescladas E se virmos nosso gráfico histórico , podemos ver aqui que temos nosso cometa ramificado, e aqui temos Amid, e aqui temos Amid, que fizemos em nosso ramal master, e Gate mesclou esses dois cometas nesta confirmação de fusão separada É assim que a fusão de três vias funciona. Você pode perguntar que a fusão tridirecional e a fusão não rápida são iguais, e eu tive a mesma pergunta quando estava aprendendo a mesclar A resposta é não. Eles não são iguais. Eles podem parecer parecidos, mas não são iguais um ao outro. A diferença é que, na fusão, temos cometas lineares e ainda queremos combinar ramificações nos novos cometas mesclados Isso é chamado de fusão não rápida. Mas na fusão de três vias, sempre divergimos cometas, obtemos ramificações combinadas automaticamente no novo cometa de Essa é a diferença entre fusão não rápida e fusão tridirecional Agora, na próxima lição, veremos como podemos remover o merge branch do nosso repositório 51. Limpar o ramo após a mesclagem: Agora, quando estamos trabalhando com ramificações no git, se concluirmos o trabalho em uma ramificação e as mesclarmos no master , não precisaremos dessa Isso criará confusão para nós e também para os membros da nossa equipe. Vamos verificar quais são as ramificações que criamos usando git branch Veja, aqui temos quatro filiais, e agora eu quero saber quais ramificações mesclamos em nossa ramificação atual, que é master Nós escrevemos git branch, dash merge. Veja, aqui temos a lista de commits que estão totalmente mesclados em nosso branch master atual Aqui obtemos todas as ramificações porque mesclamos todas essas ramificações em nossa ramificação mestre Agora, podemos remover as ramificações usando a ramificação Git, D, e escrevemos o nome da ramificação, digamos, recurso D&D. Agora, se virmos o histórico de nossos nomes, recurso DND será removido Aqui está a história do antes e do depois. Veja, basta remover o galho daqui. A empregada ficará lá como está. Atualmente, não estou removendo essas outras ramificações porque preciso delas no futuro. Agora deixe-me te dar um bônus. Em vez de observar as ramificações que estão mescladas, é fácil ver diretamente as ramificações que não estão mescladas, para que possamos mesclá-las no futuro Podemos ter em mente não derrubar esse galho por engano. Para isso, escrevemos git branch, no, d merged. Veja aqui que não temos nenhuma ramificação porque mesclamos todas as ramificações em nosso branch master atual Agora, na próxima lição, veremos como resolver conflitos no git 52. Como resolver conflitos no Git: Agora, antes de começar esta lição, quero lhe fazer uma pergunta simples. Imagine que temos duas filiais. Um é master e o segundo é o recurso slash login. Agora imagine que alteramos o arquivo SM de pontos de índice em nossa ramificação master e confirmamos as alterações. E também na ramificação de login de recursos, mudamos algo no ponto de índice STMLFle Em resumo, nessas duas ramificações, arquivo SML de pontos de índice é diferente Dessa vez, se mesclarmos essas duas ramificações , o Git confundirá quais mudanças devem ser feitas e quais devem ser evitadas E isso é chamado de conflitos no Git. Então, quando alteramos o mesmo arquivo em diferentes ramificações, e o Git pode mesclar automaticamente essas duas ramificações, isso é chamado Agora você pode perguntar quais são as possíveis soluções nas quais os conflitos ocorrem? Então, a primeira é a mudança. Alteramos a mesma linha do nosso arquivo nas duas ramificações. Depois disso, em uma ramificação, excluímos um arquivo e, na outra ramificação, alteramos esse mesmo arquivo. Também ocorrem conflitos. Além disso, renomeamos o nome do arquivo em uma ramificação e o mesmo arquivo na outra ramificação Além disso, adicionamos o arquivo TXT de um ponto na primeira ramificação e também adicionamos o arquivo TXT de um ponto na segunda ramificação, mas o conteúdo do arquivo é diferente da ocorrência de conflitos Essas são as situações comuns em que o conflito pode ocorrer. Agora, você pode perguntar o que ele fará nessa situação? E qual é a solução para resolver o conflito? Simplesmente, o git nos perguntará e nos dará as opções de quais mudanças queremos fazer Isso não interferirá no conflito. Ele simplesmente nos perguntará o que queremos fazer nessa situação? Deixe-me mostrar isso na prática. Para demonstrar o conflito, precisamos primeiro criar um conflito. Vamos escrever o Gate switch C, login do recurso e o que esse comando escreve. Ele criará uma ramificação de login de recursos e também mudará para essa ramificação. Agora, deixe-me alterar o arquivo ScrapTGS. A segunda linha, eu escrevo aqui, console dot log, console para recurso, slash login branch Salve este arquivo e deixe-me preparar as alterações e também confirmar essas alterações com a mensagem de confirmação, modifique o arquivo script dot js para login de recursos. Feito. Agora vamos mudar para o branch master e também no código VS, também mudamos a segunda linha e escrevemos aqui, Console for master branch. Salve esse arquivo. E vamos provar as mudanças. Além disso, nos comprometemos com a mensagem Modify script dot js file for master. Agora, vamos tentar mesclar essas duas ramificações. Então, executamos o Gate merge, feature slash login. Veja, aqui temos conflito e porta dizendo conflito de mesclagem no arquivo script dot JS Além disso, diz que a mesclagem automática falha e corrige o conflito e, em seguida, o resultado do commit Então, aqui temos que fazer as alterações manualmente e também podemos ver que estamos no meio da fusão Deixe-me mostrar o status atual por git status. Veja, aqui temos um caminho não mesclado. Deixe-me te mostrar uma coisa legal. Abra o código VS e veja, aqui alteramos a linha destacada, o que está causando conflito. Não se confunda com essa tela. É muito simples. Veja, primeiro obtemos o ponteiro do cabeçalho, que indica a ramificação atual que é master, e abaixo disso, temos a alteração, confirmamos na ramificação master Depois disso, temos a linha para separação e, em seguida, temos a alteração que fizemos no recurso ss login branch. Vê? Aqui temos algumas opções que o código VS nos oferece. A primeira é aceitar as alterações atuais. Se selecionarmos, ele aceitará as alterações atuais e, portanto, aplicará as alterações da ramificação atual. Vamos desfazer isso usando Control plus set ou Command plus set Agora, se selecionarmos aceitar as alterações recebidas , ele aplicará as alterações da segunda ramificação e poderemos aplicar as duas alterações, e a última opção é comparar as duas alterações Ele comparará nossos arquivos lado a lado. Então, vamos fechar esse comparativo. Aqui temos opções por código VS. Também podemos alterar o arquivo manualmente. Então, vamos remover esse recurso, cortar o ponteiro de login e também remover essa separação de linha e também remover esse ponteiro principal Se quisermos mover essas linhas para cima e para baixo , também podemos fazer isso. Mas lembre-se sempre de que não adicionamos um novo código porque o objetivo principal da mesclagem é mesclar o código de duas ramificações, não adicionar um novo código, mas às vezes precisamos adicionar novas alterações Se não for evitável, você também pode fazer isso Agora, depois de concluirmos nossas alterações, servimos o arquivo e retornamos ao terminal. Aqui, temos que primeiro configurar as alterações usando git add period Agora vamos verificar nosso status atual. Veja, não temos um caminho não mesclado. Podemos escrever um commit do Git e receber a mensagem do commit aqui Deixo como está, fecho o arquivo e vejo, mesclamos nossas duas ramificações e o estado de mesclagem também 53. Interromper o conflito no Merge: Agora, às vezes executamos o comando merge e isso nos causa conflito, mas nesse ponto, não queremos resolver esse conflito porque o conflito acontece por engano Então, em vez de avançar no estado de mesclagem, usamos esse comando de mesclagem Para isso, não vou criar uma nova filial e criar conflitos. Mostrarei minha gravação de tela anterior antes de resolvermos nosso conflito. Aqui, executamos o comando Git merge. Veja, temos um conflito. Não queremos ir mais longe, podemos escrever, distribuir, mesclar mesclar e ver que estamos nos afastando do estado de fusão 54. Redefinir o commit de mesclagem: Agora, às vezes, quando mesclamos duas filiais e nosso código para de estacionar ou travar, isso pode acontecer porque cometemos algum erro ao mesclar Portanto, existem duas soluções para essa situação. Primeiro, podemos redefinir nossa confirmação de mesclagem para a versão anterior antes da fusão E a segunda opção é que podemos desfazer nosso código de mesclagem e confirmá-lo no novo em Não se confunda com isso, deixe-me explicar cada cenário. Então, primeiro, vemos o cometa reset merge. Então, aqui em nosso Caid, nossa cabeça e nosso ponteiro mestre estão em nosso encontro de fusão Este é o nosso ponteiro de ramificação. Agora, nesta confirmação de mesclagem, entendemos o problema. Portanto, podemos reiniciar nosso cometa movendo esse ponteiro para o anterior antes de fazermos Basicamente, estamos redefinindo a camada de mesclagem para a camada anterior Agora você pode se perguntar o que acontecerá com essa confirmação de mesclagem Então, à medida que movemos nosso ponteiro mestre e principal para o anterior, essa mistura se torna inútil Depois de algum tempo, ele removerá automaticamente essa amida do nosso repositório. Agora, como podemos ver indiretamente, estamos alterando ou reescrevendo o histórico de commits, e tudo bem somente se tivermos um repositório local Mas se temos muitos membros da equipe trabalhando nesse projeto , não consideramos essa opção. Nessa situação, quando temos membros da equipe trabalhando no mesmo projeto , precisamos reverter nosso código e confirmá-lo no novo comando Então, novamente, temos nosso histórico de comprometimentos. Quando revertemos nossa mesclagem , o Git era a ponta dos galhos Agora, em vez de mover esse ponteiro com o cometa anterior, Git pega as alterações do ameta anterior, as desfaz e depois faz outro cometa, que é outro cometa Podemos ver que esse código de confirmação anterior é o mesmo que esse código de confirmação revertida Esse método é mais conveniente porque aqui não reescrevemos nosso histórico do Git Deixe-me mostrar esses dois métodos, um por um. Primeiro, vemos a opção de redefinição. Então, para isso, escrevemos git reset, dash dash hard. Nós escrevemos aqui com afinco. Vou explicar isso em apenas um minuto. E aqui escrevemos nossa referência de commit, que podemos chamar de head till one. Agora, antes de executar esse comando, certifique-se de escrever o commit a partir desse merge ammt em algum lugar em seus nós Agora, basicamente, esse comando fará com que o Git mova o ponteiro principal e principal para o commit anterior Aqui você pode perguntar: o que essa opção difícil é fazer? Então, quando executamos o comando reset, temos três opções: suave, mista e difícil. Deixe-me explicar isso em detalhes. Então, aqui temos nosso código de diretório de trabalho, código de área de teste e nosso código de confirmação Agora, quando executamos o comando reset com a opção soft, ele apenas redefinirá nosso código de confirmação para o commit específico, mas não afetará o código do diretório de trabalho do nosso código de área de teste diretório de trabalho do nosso código de área Portanto, nossas mudanças no diretório de trabalho e na área de preparação permanecerão as mesmas que temos atualmente Agora, se usarmos a opção mista de DSDs, que é a opção padrão, ela redefinirá o código de confirmação e também modificará o código de área de teste para aquela confirmação específica E agora você consegue adivinhar o que essa opção difícil faz? Certo, ele redefinirá o código de confirmação, código de área de teste e também o código do diretório de trabalho para o comando específico É por isso que usamos a opção difícil com o comando reset. Então, vamos executar esse comando. Veja, aqui está a notícia deste commit e também podemos ver a mensagem do commit. Vamos verificar nosso histórico novamente. Veja aqui que nosso head e master foram movidos para a confirmação anterior na ramificação master, e não vemos nossa confirmação de mesclagem nesta lista, mas ainda podemos passar para essa confirmação porque Get remove essa confirmação imediatamente Escrevemos git reset dash had, e aqui escrevemos esse merge commit, que é E seven, E seven, E seven, Veja agora nossa cabeça foi movida para o commit de mesclagem. Podemos ver em nossa história que obtemos a mesma mistura. Agora, na próxima lição, veremos a melhor maneira de desfazer a mesclagem, que é reverter 55. Reverter o commit de mesclagem: Agora, deixe-me mostrar a segunda opção para desfazer a mesclagem, que é reverter as alterações da mesclagem Então, para isso, escrevemos git revert, e aqui escrevemos nosso commit has, que queremos reverter No nosso caso, é esse compromisso principal. Então, escrevemos aqui, seguimos e pressionamos Enter. Veja, aqui temos um erro. Confirmar é mesclar, mas nenhuma opção foi dada. Falha na reversão. Então, de que opção o Kit está falando? Então, aqui está nosso compromisso de fusão. Quando dizemos reverter para merge commit, Git tem Primeiro, G reverterá o commit para o último commit do branch master, e chamamos esse commit primeiro pai porque estamos no branch master Agora, a segunda opção é reverter para o último cometa da ramificação característica, que é chamada de segundo pai Então, escrevemos aqui git revert M one, que é o primeiro pai da nossa ramificação atual, que é master, e qual commit queremos reverter, queremos reverter queremos reverter Queremos reverter as alterações como segundo comando principal, então podemos escrever aqui M dois, mas isso é raro Vamos mudar para aquele e pressionar Enter. Agora peça a mensagem de comando. Não quero alterá-lo, então simplesmente fecho o arquivo. Agora, vamos ver a história. Veja na parte superior, temos um novo Commit, que é o commit revertido desse commit de mesclagem É assim que podemos reverter nossa mesclagem sem reescrever Eu sempre prefiro escolher essa opção de reversão em vez de redefinir, mas, em última análise, a escolha é sua. Se o seu projeto for local, você poderá usar o que quiser. Mas ao trabalhar em equipe, reverter é a melhor opção 56. Mesclagem do squash no histórico de compromissos: Agora, antes de aprender a mesclagem de squash, que é outra técnica de mesclagem, deixe-me apresentar uma situação Então, aqui está nosso histórico de commits, e temos uma ramificação chamada Fix Bergh Login Neste ramo, corrigimos um bug em nosso recurso de login. Então, nesta ramificação, temos alguns commits F um, F dois e F três Terminamos de corrigir o bug no formulário de login. Podemos mesclar esses dois ramos. Agora, aqui, como podemos ver, esse F um, F dois e F três fazem parte do nosso histórico de commits. Mas para corrigir o bug, imagine que fizemos alguns commits incorretos, como mudar um pouco e confirmá-lo Estamos na metade da correção do bug e, apenas para pontos de verificação, criamos esses cometas Nesse caso, não queremos adicionar F um, F dois e F três em nosso histórico de commits. Portanto, a solução é que, antes de fundirmos nossas ramificações, criamos um squash kami, que é a combinação desse F um, F dois e F três, tudo em E então podemos simplesmente mover nosso ponteiro mestre para esse cometa Mas lembre-se, esta não é a fusão porque este cometa não tem dois progenitores encontrados e também podemos ver que ele não está conectado ao cometa F três Como aqui temos todas as mudanças desse galho, podemos retirar esse galho do nosso histórico conhecido, e agora temos um histórico linear e não temos uma camada de ramificação ruim. Esse é o benefício de usar o squash merge. Agora você pode perguntar: devemos sempre usar mesclagem de squash? A resposta é não. Só usaremos o squash merge quando nossos cometas ramificados estiverem ruins ou não quisermos manter os cometas na história Por exemplo, gosto de usar o squash merging quando trabalho para corrigir pequenos bugs ou recursos muito pequenos, que posso concluir em uma a duas horas As situações, eu não preciso desses postos de controle. Mas se o recurso ou bug for grande, eu não uso o squash merge e mantenho os pontos de verificação no histórico Agora vamos ver o squash merge em nosso projeto. Aqui, primeiro de tudo, vamos criar rapidamente uma nova ramificação usando o switch Git, C Fix Bugs Login Vamos ao código VS para fazer alterações, eu removo essas três linhas do console e adiro o novo registro de pontos do console Corrige o bug de login no Checkpoint one. Imagine aqui que seu horário de expediente acaba e você quer corrigir o bug amanhã. É por isso que o CheckPoint one. Salve este arquivo agora de volta em nosso terminal e, em vez de Stage e Comet em duas etapas, podemos usar aqui o atalho que é Git AM e escrever uma mensagem de confirmação, bug do porco no recurso de login, bug do porco no recurso de login Bom. Agora, para demonstrar com mais clareza, faremos mais uma confirmação neste ramo. No nosso caso, chegamos no dia seguinte ao escritório e corrigimos completamente o bug. Então, via Cd, e aqui removemos o ponto de verificação porque corrigimos o bug completamente Agora, novamente, de volta ao terminal, e aqui escrevemos gate com amfigBug no recurso de login completo Bom. Agora vamos ver a história. Veja aqui na parte superior, temos dois commits de ramificação Mas, como você pode ver , parece feio. O que é esse posto de controle? Aqui, aplicamos o squash merge. É muito simples. Basicamente, os comandos são muito simples, fazendo com que essa situação leve mais tempo aqui. Mas é importante mostrar o verdadeiro exemplo. Agora, aqui você pode perguntar: podemos pressionar por uma fusão porque não temos ramificações divergentes Sim, podemos fazer nossa fusão rapidamente, mas, neste caso, não queremos salvar esses dois cometas na Só queremos salvar as alterações, e é por isso que aqui fazemos o squash merge, que combinará as alterações desses dois ramos do cometa Primeiro de tudo, temos que mudar para nossa ramificação master. Agora, anteriormente, escrevemos para merge, Git Merge, Git Merge, Mas para o squash merge, basta adicionar aqui as opções Então, aqui podemos ver que fizemos squash Kammit. E aqui está a lista de arquivos que foram alterados. No nosso caso, temos apenas um arquivo porque alteramos apenas o arquivo JS de pontos do script, mas ele não adicionou diretamente esse commit em nosso histórico. Essas mudanças estão apenas na área de preparação. Deixe-me te mostrar. Executamos o status do Gate, C, aqui obtemos o arquivo script dot js, que é modificado. Agora podemos confirmar essas mudanças, Gate Commit. Aqui escrevemos uma mensagem de confirmação combinada, que mostra que todas as mudanças acontecem nessa ramificação Digamos que o bug da página de login foi corrigido corrigindo o tipo de dados e o endpoint na solicitação da API Bom. Agora, vamos ver a história. Veja, no topo, temos outro cometa, mas ele não está vinculado à Fix buerg slash Então, quando removemos essa ramificação de log de fix buurgs , obtemos um histórico de commits claro e linear Agora, aqui você pode perguntar, e se não removermos esse galho? Idealmente, devemos excluir a ramificação após fazer a mesclagem de squash porque essa ramificação não é declarada como a ramificação mesclada Deixe-me mostrar o que quero dizer. Se escrevermos a ramificação Ket, o painel será mesclado. Aqui, obtemos a ramificação de login do FixBurg como uma ramificação não mesclada. Mas, como sabemos, já adicionamos esse código de ramificação em nosso histórico usando o squash merge Isso criará confusão em nossa história. Portanto, é melhor descartar esse galho quando fazemos a fusão de squash Você se lembra de qual comando usaremos para derrubar o galho Não se preocupe Se você não se lembra, você também pode usar o conjunto de truques Escrevemos a ramificação Git, D, e aqui escrevemos o nome da ramificação, que é login do Fixburg Aqui temos um erro, que diz que as ramificações não estão totalmente mescladas Então, aqui temos que soltar esse galho à força. Você traz o comando anterior e simplesmente removemos esse D e adicionamos aqui D. C, nossa ramificação foi excluída com sucesso. Agora, se verificarmos nosso histórico de confirmações, limparemos seu histórico. Usamos o squash merge quando não queremos salvar commits incorretos de 57. Como rebaixar o ramo: Então, o que é rebasear no git? rebasing é uma técnica usada para alterar a confirmação base da ramificação para outra Deixe-me explicar com o exemplo. Aqui está nosso histórico de commits e estamos trabalhando na ramificação chamada features OT. Agora, aqui, enquanto estamos trabalhando na ramificação OT, digamos que alguém tenha se comprometido com a ramificação master. Agora, queremos mesclar essas alterações da ramificação master em nossa ramificação de recursos sem criar mesclagens desnecessárias Aqui, qual é a solução? Uma solução é mesclar essas duas ramificações e continuar trabalhando nelas. Mas então temos que criar também outro recurso, menos a ramificação Oth. Nós podemos fazer isso. Outra solução é que podemos usar o rebasing, o que basicamente significa que podemos mudar a base da nossa Atualmente, essa é a base de nossa filial Oth. Se mudarmos nossa base para esse último commit mestre, obteremos alterações em nossa ramificação oth sem mesclar as ramificações Isso é o que é rebase. Estamos simplesmente mudando o commit básico de nossa filial. Agora, aqui está uma coisa que você deve ter em mente : essa técnica de reformulação: reescrever nosso histórico reescrever nosso Quando mudamos nossa base para outro amet , o Git não altera o F one Kamete original Basta pegar essas duas camadas e criar o mesmo ameto que elas e , em seguida, vinculá-las à camada master mais recente e vinculá-las à camada master mais recente seguida, simplesmente mover esse ponto de ramificação aqui Agora, como podemos ver, esses comandos não estão conectados ao F para confirmar, eliminarão esse F e F para confirmar. É por isso que o rebasing reescreve o histórico do comando, e é por isso que só aplicaremos o rebasing quando estivermos trabalhando localmente Caso contrário, nossa história se tornará massa. Agora, deixe-me mostrar como podemos realizar o rebase. Primeiro, temos que criar uma nova ramificação usando o switch Git, o recurso C OT e voltar ao código VS Aqui, simplesmente criamos um novo arquivo no Jsfolder chamado auth E aqui nós simplesmente consolamos log de pontos trabalhando na autenticação. Salve esse arquivo. Agora, menos essas mudanças. E então confirme com uma mensagem no ponto norte Jspile Eu sei que essa não é uma mensagem adequada, mas para demonstração, está tudo bem. Então agora temos uma filial com uma Kat. Vamos conferir nosso histórico. Aqui, temos que fazer um kamite no master para criar kamits divergentes. Então, primeiro de tudo, voltaremos para a ramificação master. Abra o código VS e eu farei as alterações no arquivo script dot js. Então, aqui eu simplesmente removo essa mensagem do console e, aqui, algumas alterações necessárias para a ramificação OT e a salvo. Agora volte ao terminal e vamos provar as mudanças, tudo bem, e também as comprometemos. Git commit M, alterações que são necessárias para OT. Agora vamos conferir nosso histórico. Veja, agora nossa história é divergente. Se não divergirmos nossos galhos, então a marcha, por padrão, aplique a mesclagem de avanço rápido Agora temos nossos ramos divergentes. Então, temos duas opções. Podemos aplicar a fusão de três vias ou podemos rebasear. Atualmente, nossa outra ramificação está apontada para essa arte. Agora, ao rebaixamento, faremos com que nossos dois galhos apontem para este cume, que é a última empregada do mestre Para o rebase, o primeiro passo é ir para a ramificação que queremos rebasear Aqui, queremos rebasear nossa ramificação OT de recursos e, depois disso, aplicaremos o rebase Primeiro, mudaremos para a ramificação de recursos OT. Agora, qual é o comando para rebase? É muito simples. Escreva git rebase e masterize. Basicamente, estamos contando ao Git. Queremos rebasear nossa ramificação atual para o ponteiro Master, que atualmente está no comando mais recente na ramificação master Veja, revisamos nossa filial com sucesso. No mundo real, muitas vezes durante a reformulação, temos conflitos Mostrarei como podemos lidar com conflitos na próxima lição. Atualmente, nos concentramos apenas no simples rebase. Vamos ver o que teremos na história. Veja, aqui temos a história linear. Agora, se quisermos mesclá-los, primeiro mudamos para o master, depois simplesmente executamos get merge, feature OT e pronto Veja, aqui agilizamos nossa fusão porque temos um histórico linear Para explicar isso com mais clareza, aqui está a história do antes e do depois. Podemos ver que não temos o mesmo casaco. Como eu disse, criei um novo cometa, que é o mesmo que aquele antigo galho kmete Se tivermos três remédios em ambos os ramos, então podemos aqui três casacos novos Agora, na próxima lição, veremos o que faremos se tivermos um conflito durante o rebase 58. Resolvendo conflitos enquanto rebase: Agora vamos ver como podemos lidar com conflitos durante o rebase Não há nada de especial nisso. Faremos o mesmo processo que resolvemos conflitos anteriores. Mas há dois, três comandos úteis que precisamos durante isso. Então, primeiro de tudo, tenho que criar novamente uma nova filial. Digamos que eu esteja literalmente ficando sem nome aqui. Digamos que FixBugot. Agora vamos fazer algumas alterações em nosso arquivo STML de pontos de índice. Aqui, eu mudo o título do nosso site. Nesse momento, apenas escrevemos o bug Fix Auth. Diga as alterações e volte ao nosso terminal. Aqui está uma dica rápida. Se você não gosta de alternar entre duas janelas , também pode abrir o terminal no código VS. Basta pressionar Control plus Batak ou Command plus Batak. Eu gosto de usar o itbash , então mudo para ele. Primeiro, vamos organizar nossas mudanças e também nos comprometer com as mudanças Gate commit Fixburg na autenticação Bom. Agora temos que confirmar as alterações na ramificação master e na mesma linha para criar conflito. Então, vamos voltar para a ramificação master e passar para o código VS. E no arquivo STL de pontos de índice, também alteramos o título, adotamos mais pontos de exclamação Salve esse arquivo. Vamos provar a mudança e também confirmá-la com uma mensagem. Altere o título do site. Vamos conferir nosso histórico. Veja, aqui temos ramificações divergentes. Agora, simplesmente rebaseamos essa ramificação para o ponteiro mestre mais recente Qual é a primeira etapa do rebase? Mudamos para a ramificação que queremos rebasear. Mudamos para a filial da FXBurgoth. Então, o que faremos? Simplesmente, escrevemos o kit rebase master. Veja aqui que obtemos o conflito no arquivo HTML de índice. Vamos abrir o código VS e aqui podemos ver o conflito. Agora, aqui podemos selecionar entre essas três opções. Eu seleciono aqui a primeira opção, exceto as alterações atuais. Salve esse arquivo e volte para o terminal. Aqui podemos ver que estamos no processo de rebase. Agora, aqui temos apenas um conflito. Se tivermos vários conflitos, teremos que resolvê-los todos. Depois disso, simplesmente escrevemos git rebase, dash, continuamos o processo de rebase para o próximo branch comet Se o próximo commit também tiver conflitos, os resolveremos novamente e executaremos novamente o comando git rebase, dash continue Continuaremos até que todos os nossos conflitos sejam resolvidos. Então, se, para um pouco de amida, quisermos pular os conflitos , podemos usar aqui outra opção, dash dash Isso evitará o conflito atual em nosso meio. Por exemplo, temos conflito e não queremos resolvê-lo, então usamos aqui Skip Além disso, temos outra opção, que é pressionar About para falar sobre o processo de rebase sem resolver Isso é muito útil quando temos tantos conflitos e não queremos resolvê-los aqui. Então, nessa situação, podemos fazer esse processo de rebase. Veja, estamos fora do nosso processo de rebase. Agora, não estamos fazendo o rebase aqui porque é o mesmo processo que vimos na lição anterior E outra razão é que temos uma ramificação divergente que precisaremos na próxima lição É por isso que eu embarco nesse processo de rebase. Se você quiser fazer o rebase, então você pode fazer isso. Mas na próxima lição, você precisará criar ramificações divergentes Então, como você pode ver, rebase está literalmente reescrevendo a história É por isso que use o rebasing com projetos locais. 59. Técnica de colheita de cereja: Agora, aqui está nossa história de Cate. Suponha que temos, como na ramificação WigberGoth, A 1 e A. Agora, aqui, queremos copiar todo esse Evan Camt e adicioná-lo à todo esse Evan Camt e adicioná-lo nossa ramificação master ou a alguma outra ramificação Você pode dizer que podemos mesclar essas duas ramificações, mas aqui está o problema Nossa filial de Fixburgoth não está pronta para se fundir. Temos algum trabalho a fazer na filial de Wigberg slash Oth. Agora, nesse momento, usaremos uma técnica chamada cavilha de cerejeira. Quando quisermos copiar um gameta inteiro de um galho para outro, usaremos a técnica de colheita de cerejas Aqui em nosso projeto, podemos ver que temos nossa ramificação master e nossa ramificação FigburGoth com um Camt Para demonstrar com mais clareza, criaremos mais um gameta na ramificação auth. Atualmente, estamos na filial Wix per South. No código VS no arquivo scrip dot js, simplesmente adicionamos outra linha de console, escrevemos as alterações para o segundo commit do FixBugot Essas mudanças não importam porque não estamos trabalhando no projeto real. Aqui, nosso objetivo principal é aprender o git, salvar as alterações e voltar ao nosso terminal Vamos nos preparar e nos comprometer juntos. O Gate AM corrige o bug de autenticação no arquivo JS de raspar pontos. Agora você pode se perguntar por que eu uso esse comando junto e por que às vezes o uso separadamente. O comando único será executado somente quando tivermos atualizações. Se adicionarmos um novo arquivo, primeiro teremos que preparar esse arquivo e depois confirmá-lo. Bom. Agora vamos ver a história novamente. Veja, no ramo um, temos dois gametas e aqui temos um gameta no ramo mestre Agora vamos escolher esse primeiro encontro. Portanto, esse commit tem o qual queremos copiar. Para mim, é e67 90d4, onde queremos adicionar esse commit, precisamos dessa cópia do commit em nosso Primeiro de tudo, mudamos para o branch master. Agora escrevemos Cherry Pik, aqui escrevemos nosso commit, que queremos copiar Veja, aqui temos o conflito, e é por isso que eu disse para você não resolver o conflito na lição anterior, e também podemos ver que estamos no processo de escolha seletiva Quando temos um conflito, simplesmente acessamos o código VS e resolvemos o conflito. Aqui, aceitamos as alterações recebidas. Salve esse arquivo e volte para o terminal. Aqui, verificamos nosso status atual. Veja aqui que obtemos o caminho mesclado. Então, temos que organizar nossas mudanças, Gate adicionar ponto final. E agora vamos verificar novamente o status. Veja que o caminho não mesclado desapareceu. Então, agora podemos confirmar , enviar, confirmar e pressionar Enter. Abra via código e aqui escrevemos a mensagem de confirmação. No final, eu apenas escrevo uma cópia para que possamos identificar rapidamente. Vamos ver nossa história de amet. Veja, aqui temos a nova cópia kamet e ainda assim nossa filial é a mesma de antes Portanto, copiamos as alterações desse amet sem mesclar a ramificação Fibergoth em nossa ramificação master Agora, deixe-me dizer por que ela dá a essa técnica o nome de colheita de cerejas Portanto, o nome da escolha cereja reflete a natureza seletiva desse processo Então, se você ver uma cerejeira naquela árvore, temos muitas cerejas Mas para comer a cereja doce, temos que selecionar uma cereja específica da árvore e depois podemos saborear a cereja. Minha boca está ficando cheia de água. Agora que estamos colhendo cereja específica da cerejeira no git, temos uma mitra e estamos escolhendo confirmação específica e aproveitando O mesmo que colhemos cerejas. É por isso que o Git chamou essa técnica de técnica de colheita de cerejas Espero que você goste disso. Nos vemos na próxima aula. 60. Adicionar arquivo específico a outra filial: Agora, na técnica de colheita de cerejas, lembre-se de que copiamos o amet inteiro Mas e se quisermos apenas copiar um arquivo específico do Kami Então, aqui está como podemos fazer isso. Então, atualmente estamos na ramificação master, e se olharmos nosso arquivo script dot js , aqui, obtemos apenas duas linhas de console. Agora, se mudarmos para a ramificação FXBurgoth e vermos, em nosso arquivo script dot js, obteremos duas Agora, queremos copiar esse arquivo script dot js do FXBurgothBranch e adicioná-lo ao nosso branch e adicioná-lo ao Voltamos novamente para a ramificação master porque queremos adicionar o arquivo na ramificação master. Aqui escrevemos o Git, restauramos a fonte igual a, e aqui escrevemos nome da nossa marca da qual queremos copiar o arquivo, que é Agora, depois disso, escrevemos o caminho do arquivo que queremos copiar. Nós escrevemos o script Js dot js. Certifique-se de escrever o caminho do arquivo, não apenas o script dot js. Caso contrário, você receberá um erro. Aqui também podemos separar o nome do arquivo do comando usando um traço duplo. Nós já vimos isso. Lembre-se de que aqui estamos informando para obter o arquivo copy script dot js, versão mais recente da ramificação WigberGoth, e colá-la em nossa ramificação master atual Agora, se verificarmos nosso arquivo script dot js, aqui obtemos duas linhas de console que são iguais do FixBurgoth Agora podemos configurar os queixos e, se você quiser se comprometer , também podemos confirmar nosso código É assim que podemos copiar um arquivo específico de uma ramificação para outra ramificação. 61. Branch e Merge no VS Code: Agora vamos ver o recurso de ramificação e mesclagem em nosso código VS. A primeira coisa que quero esclarecer é código do VS não tem todos os recursos, o que fazemos usando comandos git Então, vamos ver o que temos no VSCode. Abra o controle do código-fonte. Aqui, obtemos nossos arquivos de palco e estágio. Nós já vimos isso. Agora aqui na parte inferior, depois vem, temos a seção de galhos. Aqui, podemos ver todas as nossas filiais. Temos o master Fix BouGot e temos uma pasta de ramificação de recursos Agora você pode perguntar: não criamos essa pasta de recursos. Então, quem criou isso? Deixe-me dizer que criamos isso porque usamos a barra no nome da ramificação e, para todas as ramificações de recursos, usamos a barra de recursos no nome da ramificação É por isso que temos aqui a pasta de recursos. Se tivermos mais de uma ramificação com o Fix Berg , também obteremos aqui a pasta Fix Berg. Agora, aqui podemos ver que atualmente estamos na ramificação master porque temos aqui o Tick Mark. Além disso, podemos mudar de filial a partir daqui. Além disso, podemos criar uma nova ramificação a partir daqui. Também temos ver a ramificação como lista e mais algumas opções. Agora, se clicarmos em qualquer ramificação, aqui podemos comparar a opção. Selecione o, e aqui escrevemos o nome da nossa marca que queremos comparar. Digamos que PisBurgot. Veja agora essa opção convertida em menu suspenso. Podemos ver aqui os arquivos que foram alterados ou afetados. Atualmente, não temos nenhum arquivo aqui, mas se tivermos arquivos , clicando neles, podemos ver as alterações. Agora, deixe-me mostrar como podemos realizar a fusão. Clique com o botão direito do mouse na ramificação Fix Burg Oth e selecione mesclar na ramificação atual Aqui, temos muitas opções de mesclagem. Primeiro, temos merge, que é o comando simples de mesclagem, como git merge como git merge Depois disso, temos uma fusão rápida. Aqui podemos ver que temos apenas um avanço rápido. Com isso, estamos dizendo ao gait, use apenas a mesclagem rápida, se possível Caso contrário, deixe como está , sem mesclar. Em seguida, temos o squash merge, depois não temos o fast forward merge e, finalmente, temos sem avanço rápido e sem confirmação, ou também podemos cancelar ou quase Vamos simplesmente selecionar a mesclagem padrão, fechar esse arquivo de mensagem de confirmação e ver a mesclagem Agora, se virmos nossas amidas , chegaremos aqui merge commit. Agora, se escrevermos vazamento no Camt anterior, teremos aqui a opção de reversão Aqui, selecionamos a reversão simples e vemos aqui a curva de reversão. Agora também podemos reiniciar nosso Camt. Aqui temos algumas opções: suave, dura ou mista. Por enquanto, vamos cancelar isso. Como podemos ver, esse controle de origem é muito confuso para filiais Eu quase não uso esse controle de origem para filiais. Para filiais, instalamos a extensão Git Lens, que é uma ótima ferramenta Aqui, clique no ícone do Git Lens. Aqui, em primeiro lugar, obtemos o ícone do gráfico Commit. Clique nele e veja, aqui temos o gráfico do Commit. Agora, para ver isso com mais clareza, fecho essa extensão de lente Git e também fecho todos esses arquivos da parte superior e clico nessa opção de abrir na área do editor Vamos fechar a janela do terminal. Veja que este gráfico parece mais claro. Veja, no início deste projeto, temos uma história linear. Em seguida, criamos nosso feedback sobre os recursos da ramificação e, em seguida, os mesclamos na ramificação master Depois disso, criamos outra ramificação e, novamente, as mesclamos no master Agora, no topo, podemos ver aqui que temos uma filial. Agora, se clicarmos em qualquer ramificação, temos algumas opções. Primeiro, mudamos para outra ramificação, redefinimos as alterações, renomeamos a ramificação, criamos a ramificação, criamos a tag, etc Agora vamos criar uma nova ramificação aqui. Insira o nome da filial. Digamos que Vicksburg reduza o registro . Pressione Enter e aqui temos três opções. Crie uma ramificação, crie, alterne e cancele. Então, selecionamos Criar e alternar. Agora vamos abrir um arquivo, pressionar Control plus P ou Command plus P e abrir o arquivo JS de pontos Aqui, fazemos algumas mudanças. Salve esse arquivo e vamos confirmar essas alterações. Então vá para Source Control. E aqui escrevemos nossa mensagem de confirmação. Digamos que trabalhe no registro do Fix Berg e pronto. Agora, vamos voltar ao gráfico de Confirmações. Veja aqui que podemos ver nossa ramificação ativa atual é FixBurglRegistration, e Agora, se clicarmos com o botão direito do mouse na ramificação master , obteremos aqui mais opções, alternaremos para a ramificação, mesclaremos com a ramificação atual, rebasearemos, renomearemos e Veja, aqui temos as mesmas opções que temos no controle de origem. Na próxima lição, veremos como podemos ver ramificações e mesclagens no Github 62. Branch e Merge no Github Desktop: Como sabemos, para interfaces gráficas de usuário, temos dois aplicativos. O primeiro é o Github desktop e o segundo é o Kraken. Se tiver certeza de que deseja usá-lo no Kraken, você pode pular esta lição e ir diretamente para a lição do Git Aqui está a interface do aplicativo de desktop Github. Agora, para filiais, temos aqui uma lista de filiais. Veja, aqui podemos ver nossa filial atual. Agora, para trocar as ramificações, basta clicar nessa ramificação. Veja, nossas filiais mudaram. Aqui no topo, temos a opção de criar uma nova filial, o que é muito simples. Agora, aqui na parte inferior, temos a opção de mesclar a ramificação do seletor com a ramificação Vamos selecionar isso e aqui, temos que selecionar a ramificação que queremos mesclar Digamos FixBurgRegistration, que criamos Clique em FixburgRegistration. Vamos selecionar Rate Merge Camt. Se tivermos um conflito , podemos resolvê-lo a partir do código VS e continuar a fusão Aqui, recebemos a mensagem de sucesso da mesclagem e, se verificarmos nosso histórico de confirmações, você poderá ver a confirmação da mesclagem Agora, se quisermos acessar mais opções de ramificação , temos esse menu de ramificação. Aqui, podemos criar uma nova ramificação, renomear, excluir, comparar, mesclar na ramificação atual, mesclar , rebase, etc Agora, deixe-me mostrar uma comparação. Então, em comparação com a filial, e aqui temos opções para comparar. Mas, como você pode ver aqui, não podemos ver corretamente o histórico de commits com branches. É por isso que muitos desenvolvedores não gostam do desktop Gitub. Se você gosta do Gitub desktop, pode usar o histórico de Commit do VS code para observar os commits e a ramificação e , em seguida, usar Merge Tool no Essa é a melhor opção. Em última análise, a escolha é sua. 63. Branch e Merge no GitKraken: Agora, vamos abrir o aplicativo Git Kraken. A história penal ainda é meu coração. Veja como está lindo. Podemos ver claramente as ramificações e o histórico de commits muito melhor do que usar o código VS ou o aplicativo de desktop Github Veja, aqui temos um gráfico claro para filiais, que podemos entender facilmente. No topo, podemos ver a lista de filiais. E se selecionarmos qualquer ramificação , podemos mudar para essa ramificação. Muito simples. Deixe-me mostrar como podemos criar uma nova filial. Clique com o botão direito na ramificação e aqui temos várias opções. Vamos selecionar Criar uma nova ramificação. Aqui, damos o nome da filial. Digamos que a barra de recursos Saia. Aqui podemos ver que obtemos a mudança automática para essa ramificação. Agora vamos fazer alguns amas neste ramo. Voltando ao código VS, openscrip dot sple e simple, finalmente, nós, no console dot log, implementamos As mudanças e vamos confirmar essas mudanças. Dê a mensagem de confirmação. Digamos que implemente o recurso Logout e o confirme. Dica rápida aqui, se quisermos ver a ramificação ativa atual , podemos ver daqui no código VS. Também a partir daqui, podemos mudar para o outro ramo. De volta à ramificação Master, e aqui também const dot log e adicionamos atualizações no arquivo script dot js Vamos também confirmar com a mensagem, atualizar o arquivo gs do script. Sabe, essa não é uma boa mensagem de confirmação, mas é apenas para demonstração. Agora, voltando ao Kraken, podemos ver como o galho diverge, Lovely Agora, antes de fazer a fusão, vamos ver como podemos comparar duas ramificações Selecione a ramificação de desconexão e mantenha-se seguro. E selecione o outro ramo que é mestre. Veja no lado direito, temos a diferença de duas ramificações e, abaixo disso, temos uma lista de arquivos afetados. Se selecionarmos o arquivo , abriremos o arquivo com as alterações. Eu mudo intencionalmente aqui a mesma linha, então temos conflito na linha três e vamos fazer a fusão Selecione a ramificação master e perna direita na ramificação de logout que queremos mesclar Aqui temos a fusão e também o rebase Vamos selecionar Mesclar. Veja, aqui temos o conflito, e aqui temos todos os arquivos conflitantes Selecionamos o arquivo script dot JS e aqui temos essa bela ferramenta de mesclagem Aqui, no lado esquerdo, temos as alterações do master, e no lado direito, temos as alterações da ramificação Logout e, na parte inferior, temos a saída final Aqui, podemos selecionar as ramificações marcando a caixa de e também podemos selecionar as duas. Também podemos sair daqui e, se tivermos mais de um conflito , podemos vê-los daqui para cima e para baixo. Agora, quando nos satisfazemos com nossos conflitos , simplesmente salvamos as alterações aqui. Agora, no lado direito, temos a lista de arquivos de estágio. Também temos uma mensagem de confirmação pronta. Agora temos aqui duas opções, Comte e mesclar, e prestes a Vamos usar Commit e mesclar. Veja aqui no topo, temos T merge Comte Muito simples e fácil. Agora imagine que recebemos um erro em nosso código a partir dessa fusão. Também podemos reverter ou rebasear nosso Commit. Clique com o botão direito do mouse em Confirmar e selecione a opção reverter Confirmação Pediremos a confirmação imediata, Kat. Selecionamos sim, C, aqui obtemos Kumt revertido. Agora, se você quiser redefinir a amida para essa amida antes de fazermos a fusão, podemos escrever, clique aqui e selecione Aqui, temos três opções: macia, mista e dura. Nós já vimos isso certo. Agora, aqui está uma coisa. Imagine que você não aprenda os comandos git antes de usar o Git Kraken ou qualquer interface gráfica de usuário, então você definitivamente entrará É por isso que decidi ensinar primeiro os comandos do Git e depois as interfaces gráficas de usuário como o Git up desktop e o Git Aqui vamos para reinicialização total e nossos comandos de mesclagem e reversão desaparecem É assim que podemos trabalhar com ramificações e mesclagens no Git Kraken Sei que esta seção é um pouco mais longa, mas todas essas são lições de mesclagem muito importantes Então você fez um ótimo trabalho. Dê a si mesmo um pequeno presente, ouça música, jogue alguns jogos ou faça uma nova caminhada. Continuaremos nossa jornada de domínio de kits na próxima seção Então, nos vemos na próxima seção. 64. Seção 05 Trabalhando com equipe: Bem-vindo à quinta seção do curso definitivo do Kit. Nesta seção, veremos como podemos trabalhar em equipe usando o Git Atualmente, nosso repositório está em nosso ambiente local, mas no mundo real, temos que trabalhar no repositório na nuvem Então, você pode se perguntar: como podemos trabalhar com outros membros da equipe em uma empresa? Aprendemos como podemos buscar alterações de outros membros da equipe, publicar nossas alterações, pull requests, problemas e muito mais. Eu sei que você está animado com esta seção, e eu também estou animado com isso. Então, sem perder tempo, vamos entender como trabalhamos em equipe em um único projeto usando o Git 65. Visão geral do trabalho em equipe: Então, como eu disse, até agora estamos apenas trabalhando localmente. Mas no mundo real, não trabalhamos sozinhos. Há muitos desenvolvedores trabalhando em um único projeto, e é por isso que veremos uma visão panorâmica de como os desenvolvedores trabalham juntos no mesmo projeto usando-o. Então, deixe-me fazer uma pergunta simples. Aqui está nosso repositório. Como você acha que outros membros da equipe podem trabalhar com esse repositório Uma solução é hospedar esse repositório em algum lugar do servidor e todos os desenvolvedores trabalharem em um único repositório Isso é chamado de sistema centralizado de controle de pessoas. Agora, e se esse servidor no qual tínhamos nosso repositório ficar offline ou entrar em manutenção Então, todos os desenvolvedores precisam sentar e esperar que o servidor saia da manutenção. Essa abordagem não está funcionando corretamente. Agora, outra solução é para cada desenvolvedor, nós damos a eles um repositório em seu próprio PC ou laptop Eles não dependem de nenhum servidor. Eles podem trabalhar em seu repositório a qualquer momento. Isso é chamado de Vers distribuídos e sistema de controle, e o Git é o exemplo desse sistema distribuído de Vs e controle Agora você pode perguntar se todos os desenvolvedores trabalham em seu próprio sistema, então como eles podem colaborar com os membros da equipe Para trabalhar em equipe, aderimos a um repositório centralizado entre todos os desenvolvedores Todos os desenvolvedores têm seu próprio repositório, mas também temos um repositório central que eles usam para colaboração Deixe-me explicar isso com um exemplo do mundo real. Suponha que seja você e esse seja eu. Aqui estamos trabalhando em um mesmo projeto, que é, digamos, um aplicativo de comércio eletrônico. Agora, primeiro, clonaremos nosso projeto existente para nós dois em nosso sistema pessoal Agora, suponha que você trabalhe em sua tarefa, faça algumas câmeras e, quando estiver pronto, envie essas alterações para esse repositório Agora temos atualizações no repositório, então eu sou notificado com isso Eu abro este repositório e obtenho as alterações no meu sistema. Agora meu código e o código desse repositório se tornam os mesmos Mas imagine que eu entendi aqui um conflito. Eu resolvo o conflito aqui na minha máquina e, em seguida, envio meu código para este repositório Agora, você e outros desenvolvedores podem obter esse código atualizado e continuar trabalhando neste projeto. Isso é chamado de fluxo de trabalho centralizado e , obviamente, siga esse fluxo de trabalho centralizado Não se confunda. O fluxo de trabalho centralizado e o sistema de controle e controle centralizados não são os mesmos São coisas diferentes, só que os nomes são parecidos. Acompanhe esse trabalho centralizado Agora, algumas empresas usam seu próprio servidor privado para hospedar esse repositório em sua empresa, mas manter um servidor próprio é pouco caro para Portanto, novas empresas gostam de usar algum servidor baseado em nuvem que possa hospedar seu repositório de forma privada Essa é uma opção barata e boa para novas empresas e startups. Existem muitas empresas que fornecem esse tipo de serviço em nuvem para hospedar o repositório, e você acertou O Github é uma das plataformas de hospedagem de repositórios. Também temos Gitlab, Bitbucket, GIT e muito mais Mas todos nós sabemos que o Github é uma das plataformas mais populares, então usaremos o Github Você está usando qualquer outra plataforma de hospedagem, ainda assim, você pode continuar este curso porque estamos falando sobre trabalhar em equipe. Realmente não importa qual plataforma de hospedagem você usa. O que quer que você faça no Github, acho que tudo o básico pode ser feito em outra plataforma de hospedagem de repositórios Agora, e se você estiver trabalhando sozinho? Nessa situação, você também pode usar o Gitub para armazenar nosso código como backup Até 20 a 40% dos desenvolvedores usam o Gitub para armazenar suas linhas e gerenciar seu currículo No futuro, eles não perderão o código. Ele também estará disponível em sua conta do Github. É benéfico para você aprender isso. Agora, na próxima lição, veremos esse fluxo de trabalho em andamento. Estou muito empolgado com isso. 66. Como fazer upload do projeto no github: Agora, antes de começarmos a criar um novo repositório, muitos estudantes me perguntam: como posso fazer o upload do nosso projeto Git existente no Deixe-me mostrar como podemos fazer upload de projetos locais no Github. Primeiro, veremos o upload do projeto usando o Github Dektop e, depois disso, mostrarei Então, primeiro, eu abro o Github Dektop aqui, primeiro, verificamos se nosso repositório Se não estiver disponível nesta lista, acessamos o arquivo no repositório local e simplesmente navegamos até essa pasta e abrimos nosso projeto aqui Agora, se não tivermos nenhuma alteração, chegaremos aqui diretamente à opção de publicar repositório Caso contrário, também temos essa opção aqui após a opção de ramificação. Aqui podemos ver esse repositório disponível apenas em sua máquina local Ao publicá-lo no GitHub, você pode compartilhá-lo e colaborar com Então, clique neste botão de repositório público. Receberemos esse pop-up que solicita o nome do repositório. Eu dou a ele a faixa Tas para Git. Se você quiser escrever uma descrição , pode escrevê-la aqui. A partir daqui, podemos tornar nosso repositório privado ou público. Se tornarmos nosso repositório uma república , qualquer pessoa na Internet poderá assistir ao nosso código Uma coisa é que, se você quiser colaborar com outras pessoas , precisamos tornar nosso repositório público Se o tornarmos privado, teremos que pagar pelo repositório privado para colaboração Se você quiser apenas armazenar código , podemos usar o repositório privado Estou desmarcando essa caixa para o repositório público e simplesmente clico em Veja a publicação. Se você quiser verificar , podemos verificar nosso repositório no Github usando este botão É assim que é simples. Agora, deixe-me mostrar como podemos fazer o mesmo usando o aplicativo Git Kraken Abra o aplicativo Git Kraken e selecione nosso repositório que você deseja publicar Agora, antes de publicar o repositório, precisamos conectar nossa conta do Github ao aplicativo Get Kraken Então, clique nesse botão de configuração a partir daqui e vá para a guia de integração. Aqui temos alguns serviços de hospedagem, por padrão Github, e aqui não estamos conectados Vamos nos conectar ao Github. Ele solicitará que você faça login com sua conta do Github. Eu faço login com minha conta. Ele solicitará que façamos login ou autorização. Eu autorizo e aqui escrevo minha senha e simplesmente abro o Crack e o aplicativo Veja aqui que obtemos nossa conta. Agora vamos fechar essas configurações. Nós não precisamos disso. Agora, para publicar um repositório, precisamos primeiro adicionar remoto, clicar neste ícone de nuvem que é para remoto e aqui podemos ver que não temos nenhum controle remoto Assim, podemos criar novos. Aqui, podemos ver que selecionamos o Github e ele solicita o nome do repositório, o nome remoto, que vemos nesta lista remota, descrição do repositório, e também podemos torná-lo público Não se preocupe, basta clicar em Criar controle remoto e apertar o botão de rotações locais E então recebemos uma mensagem de sucesso. Também podemos ver isso no github.com. Isso parece um pouco complicado porque pressionamos todos os nossos Camts de uma só vez Mas no mundo real, primeiro criamos nosso repositório e depois trabalhamos nele. Então não se preocupe com isso. Agora, na próxima lição, criaremos um novo repositório usando site do Github e aprenderemos conceitos da seção em seu Então você não se confunde com esse projeto mestre. 67. Como criar um novo projeto no github: Então, abra github.com e, se você não tiver uma conta no Gitub, poderá criar facilmente uma É muito simples e fácil. Além disso, verifique sua conta de e-mail antes de criar um novo repositório Eu já entrei com minha conta aqui. Agora, para criar um novo repositório, clique neste ícone de adição Aqui temos um novo repositório e também podemos importar o repositório de outro lugar Vamos buscar um novo repositório. Aqui, primeiro inserimos nome do nosso repositório, que queremos fornecer Digamos, CardWishGT porque eu tenho o repositório Cardwisname Agora, aqui, podemos escrever uma descrição desse repositório. Em seguida, temos a opção pública ou privada. Como eu disse antes, se selecionarmos privado , teremos que pagar pelo trabalho em equipe. Então, selecionamos aqui público. Agora, aqui temos algumas opções. Você pode adicionar um arquivo ad me, no qual podemos escrever uma descrição longa para nosso projeto ou site, e também podemos selecionar o arquivo Getting nor. Aqui temos uma lista de idiomas. Por enquanto, não queremos isso e clicamos em Criar repositório E então criamos um novo repositório. Aqui na parte superior, podemos ver nosso nome de usuário e cortar o nome do nosso repositório Se alguém pedir que você veja seu código, você pode fornecer a essa URL do Github Mas, para isso, você precisa de um repositório público. Caso contrário, as pessoas não verão isso. Agora, aqui temos nossa lista de filiais. Atualmente, temos apenas uma filial, que é a principal. Esse principal é o mesmo que nosso branch master. O Github chamou o branch master como principal. Depois disso, temos o número de ramificações e também obtemos o número de tags. Aqui podemos pesquisar um arquivo específico. Além disso, podemos criar um novo arquivo e também podemos fazer upload de arquivos. Agora, nesta caixa quadrada, podemos ver nosso projeto. Aqui podemos ver nosso último Commit. Agora você pode perguntar, não cometemos nada. Este é o commit que o Github cria para criar um novo repositório Aqui, podemos ver que o Commit tem tempo quando foi confirmado e todos os commits. Vamos verificar isso. Aqui temos a lista de commits. Podemos filtrá-lo por usuário a partir daqui e também podemos filtrá-lo por hora. Agora, a partir daqui, podemos ver os commits por branches e, se quisermos ver mais detalhes sobre o commit, podemos clicar aqui Aqui, obtemos o galho que é principal. Recebemos o nome de usuário e também o horário. Depois disso, podemos ver o arquivo alterado com duas adições e zero exclusão e podemos ver essas linhas aqui Bom. Volte para nossa página de código. Aqui, obtemos a lista dos arquivos do projeto e, no lado direito, também recebemos a mensagem de confirmação. Em qual comando esse arquivo é adicionado ou alterado. Também podemos ver o conteúdo do arquivo aqui. Há uma pequena introdução sobre o repositório Github. Agora, na próxima lição, veremos como podemos adicionar membros da equipe nesse repositório 68. Adicionando membros da equipe ao projeto: Atualmente, nosso repositório é público, mas ainda assim ninguém pode enviar commits em nosso Você pode dizer que já tornamos nosso repositório público e ainda assim ninguém pode enviar commits por push Por quê? Repositório público significa que todos podem ver nosso repositório, mas precisamos adicionar os membros da nossa equipe como colaboradores nesse Aqui vamos para a opção de configuração. Na seção de acesso, temos a guia de colaboradores Aqui podemos ver que não temos contribuidores. Vamos adicionar um membro da equipe a esse projeto. Aqui, adicionamos um membro e podemos pesquisar a conta dos membros da equipe usando nome de usuário, nome completo ou conta de e-mail. Eu escrevo minha segunda conta. Esta é minha nova conta que criei para este curso. Se eu não aceitar seu convite , desculpe porque provavelmente não vou acessar essa conta no futuro. Se você não tiver outra conta, poderá criar uma segunda conta para esta seção ou convidar seus amigos que também desejam aprender o Git Dessa forma, você entende melhor essas lições. Veja como esse usuário e clique em adicionar a este repositório. Aqui, temos um colaborador, mas, como podemos ver, temos um convite pendente Quando você adiciona alguém ao seu repositório, Git envia solicitações de colaboração por Se a pessoa aceitar o convite, parabéns. Você tem um colaborador. Mas essa pessoa também tem a opção de rejeitar. É assim que podemos adicionar membros da equipe ou colaboradores em nosso repositório 69. Repositório Git de clonagem em nossa máquina: Então, como sabemos, criamos um novo repositório a partir da nossa conta do Github. Mas como podemos começar a trabalhar nesse repositório? Porque não temos esse repositório em nossa máquina. Vamos ver como podemos adicionar ou clonar repositório do Github Vá para a opção de código e aqui temos o link do nosso repositório no Github Copie isso e abra a pasta na qual você deseja clonar esse repositório Então, estou na pasta do meu projeto, abra o Gitwsh ou o terminal nesta Aqui, apenas escrevemos Gate, clonamos e colamos nosso URL Se você estiver usando o Windows , o Control plus V não funcionará. Então clique com o botão direito aqui e veja, temos a opção de página e também temos um atalho para isso Agora, se executarmos esse comando , clone este repositório com o nome do repositório como nome Além disso, se você quiser alterá-lo , também podemos fazer isso. Digamos que eu só queira cartwish e aperte Enter. C, clone este repositório. Agora temos todos os cometas, todas as ramificações, literalmente todos os detalhes sobre o repositório tet Vamos entrar nessa pasta de carrinhos. Então mude o diretório para cartwis. Agora vamos ver os casacos, então git log, dash dash p line, dash dash all, dash dash graph Agora, aqui temos um único comando, que é o comando inicial. Aqui, podemos ver que nosso ponteiro principal está neste comando, mas temos mais dois ponteiros aqui, origin main e origin Quem criou isso e por quê? Então, como sabemos, o headpointer é usado para saber em qual commit estamos, e main é nossa ramificação padrão Agora, quando clonamos nosso projeto do GitHub, Git cria uma ramificação remota e a nomeia como Esta não é a filial original. Esta é apenas uma filial remota. Se tentarmos mudar para a filial , isso não funcionará. Também podemos verificar isso usando git branch. Veja aqui que temos apenas uma filial que é a principal. Agora, deixe-me te mostrar algo útil. Se escrevermos gate remote , aqui obteremos nosso repositório remoto que é a origem Você pode perguntar: o que é repositório remoto? Um repositório remoto é o projeto ou repositório hospedado no servidor, como o Github ou Em palavras simples, o repositório remoto é, o que não está em nossa máquina local Nosso repositório atual não está apenas em nossa máquina local, ele é armazenado em um local remoto, como no Github Esse repositório remoto , chamado origem, é usado para fornecer informações sobre nosso projeto Github. Como em qual filial os desenvolvedores estão trabalhando atualmente e muito mais. Agora, por esse motivo, o Git cria mais dois ponteiros Origins main ou master e origins head Deixe-me explicar isso com o exemplo. Suponha que eu e você trabalhamos no mesmo projeto e nós dois clonamos nosso projeto do Github Agora, quando clonamos nosso projeto do GitHub , o Git cria esses dois ponteiros origin main e origin head Agora, suponha que eu trabalhe em um recurso e coloque a Cam em nosso repositório Mova este ponteiro principal de origem para este encontro tardio na ramificação principal Então, essencialmente, origin main nos dirá onde as mudanças mais recentes acontecem em nosso repositório Github Portanto, se outra pessoa fizer outro cometa, o ponteiro principal de origem se moverá para esse Você pode dizer que entende as origens principais, que representam as mudanças mais recentes em nosso repositório Mas por que essa cabeça de corte de origem também está se movendo com essa origem como principal. Honestamente, não está se movendo. Está no mesmo galho. O chefe do Origin é usado para nos dizer qual é a última filial a ser finalizada ou, em palavras simples, qual é a última visualização da filial ou trabalho de qualquer membro da equipe Suponha que aqui tenhamos essa ramificação da página de produtos em destaque. Se você for eu ou algum desenvolvedor mude para qualquer outra ramificação, esse cabeçalho de origem apontará para essa ramificação. Então é assim que esse ponteiro funciona. Então, para resumir, apenas o ponteiro principal é usado para nos dizer em qual commit estamos trabalhando atualmente Origin Min ou Origins Master nos dizem onde as mudanças mais recentes acontecem em nosso repositório Github Com isso, podemos conhecer as últimas mudanças em nosso repositório Github Origins HAD nos diz qual é a visão mais recente da filial ou o trabalho de qualquer membro da equipe. Não se preocupe com isso. Todas as dúvidas ficam claras quando veem tudo isso em ação. 70. Obtendo as mudanças: Então, como sabemos, este é o nosso repositório Gitub, e este é o nosso repositório local, que clonamos Agora, esses dois repositórios não estão conectados entre si Então, quando alguém coloca as alterações neste repositório gitub , não recebemos esses commits automaticamente Precisamos executar o comando Git fadge para obter os novos commits em nosso Aqui precisamos prestar atenção. Atualmente, em nosso repositório local, estamos trabalhando no cometa C one Nosso ponteiro principal, ou podemos dizer , mestre ainda está neste cometa Mas, como eu disse na lição anterior, nosso ponteiro principal de origem avançará porque representa as alterações mais recentes no repositório remoto Ao usar o comando patch do Git, obtemos a desconfirmação, mas nosso ponteiro principal ou principal ainda está em nossa confirmação C Portanto, obtemos a desconfirmação em nosso histórico, mas nosso diretório de trabalho ainda não foi afetado e, com isso, não temos nenhum conflito Agora, se você se sentir confortável em aplicar essas alterações em seu diretório de trabalho , podemos executar git merge e esse nome de ponteiro, e esse nome de ponteiro, que é Portanto, aqui não temos filiais diversas. Que tipo de mesclagem o Git executa. Absolutamente certo. Git perform pass for or merge E se tivermos algum conflito, então o resolvemos da mesma forma que resolvemos anteriormente e pronto. Digamos que esse patch do Git seja prático. Então, neste navegador, eu faço login com minha outra conta do Github E nesta máquina, tenho minha conta original, que é Deus te abençoe Aqui só temos meu arquivo. Então, vamos alterar esse arquivo e simplesmente confirmá-lo. Clique nesse arquivo e, a partir daqui, podemos editar esse arquivo e alterar esse texto. Isso é para uma segunda confirmação e simplesmente confirme as alterações. Aqui, podemos escrever a mensagem de confirmação. Eu deixo como está. Aqui, certifique-se de selecionar Confirmar com a ramificação principal. Também podemos criar uma nova ramificação a partir daqui com esse commit. Mas veremos essa opção na próxima lição. Basta clicar em Confirmar. Agora, de volta à nossa janela de código, veja, aqui temos dois cometas. Agora, se vemos em nosso repositório local , aqui temos apenas um encontrado Agora vamos ver como podemos buscar do nosso repositório remoto Escrevemos git fetch e, em seguida, escrevemos nosso nome remoto que é origin Nós não escrevemos nada, então, por padrão, o Git tem origem Veja, é um patch. Agora vamos conferir nosso histórico. Veja, chegamos aos cometas, e também podemos ver origem principal e a cabeça de origem serem movidas para este cometa, mas nossa cabeça ainda está Agora, vamos ver como podemos adicionar essas alterações em nosso diretório de trabalho. Sugira que escrevamos git merge e escrevamos nosso nome de ponteiro, origins main e escrevamos nosso nome de ponteiro, origins main. E nós terminamos. Veja aqui que agilizamos nossa mesclagem e também podemos ver em nosso histórico que o ponteiro principal é movido para nosso segundo comando e também abrimos o arquivo IDM no código VS e, em seguida, obtemos o arquivo seguida, obtemos o 71. Retire as mudanças: Na lição anterior, vemos que, para obter as alterações mais recentes do repositório remoto, precisamos usar o comando patch e, em seguida, para adicionar as alterações em nosso diretório de trabalho, precisamos mesclá-las Como podemos ver, essa é uma abordagem em duas etapas. Também podemos fazer isso em uma única etapa, e você sabe por qual comando ele é puxado? Suponha que temos essas amds no repositório local e no repositório remoto Aqui nos comprometemos em nosso repositório local e aqui outro membro da equipe também adiciona amid ao repositório remoto Agora, se executarmos o comando git pool, Git adicionará esse commit sit em nosso repositório local e Min Pointer de origem será movido Agora, mescle essas duas mudanças e crie uma nova camada. Agora, muitos desenvolvedores não gostam dessa abordagem porque podemos ver que ela está criando um novo pacote de mesclagem e também recebemos comandos divergentes A outra solução, em vez de fazer a mesclagem, também podemos realizar o rebase Assim, podemos executar o comando git, pull, rebase, e isso rebaseará nosso comitê para este commit principal de origem slash, e é assim que obtemos um histórico linear Agora, qual é a melhor opção para pull, merge ou rebase? Honestamente, isso realmente depende da nossa situação. Provavelmente, seu gerente lhe dirá para usar mesclagem ou rebase, não se preocupe com isso Pessoalmente, gosto de usar o rebase em vez de usar o merge porque nosso histórico de commits permanecerá limpo Então, vamos ver isso em nosso repositório. Portanto, para pull request, primeiro precisamos confirmar algumas alterações em nosso repositório local, bem como no repositório remoto Então eu abro nosso repositório local no código VS e crio um novo arquivo, digamos, scrap dot js, aqui mesmo, console dot log Este é um arquivo copiado. Salve as alterações e vamos confirmá-las. Voltar para Git Bash it Ed period, c staging e Gitatm createscript c staging e Gitatm createscript dot Jsfile para JavaScript. Agora vamos conferir nosso histórico. Veja, aqui temos três Camits e nossa cabeça é movida para nossa última amit e origin main e a cabeça de origem ainda está neste Commit Agora vamos criar o Cait em nosso repositório remoto. Vá para a segunda conta. E aqui eu crio um novo arquivo a partir daqui, e aqui escrevemos o nome do nosso arquivo. Digamos que os planos pontuem TxD. Fisicamente, escreverei planos neste arquivo. Então, passo número um, crie um layout de site básico para este projeto. Agora, vamos confirmar isso, então confirme as alterações. Deixo essa mensagem de confirmação como está e vou para Confirmar. Feito. Veja, aqui temos três commits Agora, de volta ao nosso Git Bash. Aqui, executamos o comando git pull, então isso adicionará nosso commit de repositório remoto em nosso projeto e, em seguida, o mesclará Ele solicitará uma mensagem de confirmação. Eu não quero mudar isso, então feche isso. Veja, a fusão está completa. Vamos conferir nosso histórico. Veja, aqui temos a confirmação da fusão e também os casacos de mergulho. Agora, deixe-me mostrar como podemos rebase com pull. Antes disso, vamos desfazer essa confirmação de mesclagem. Então, git reset, d dash hard, e queremos dar um passo antes Então vá até um. Confira nosso histórico. Veja, redefinimos nossa fusão e obtemos essa ramificação separada Então, vamos executar git pull, rebase. Basicamente, estamos dizendo ao Git que rebaseie nosso commit atual no ponteiro principal de origem e veja se recebemos Vamos verificar nosso histórico mais uma vez. Veja, temos uma história linear, e essa origem principal é mover para cá. Agora, na próxima lição, veremos outro comando muito útil, que é o comando push. 72. Enviar alterações para o repositório remoto: Agora, atualmente, em nosso repositório local, temos quatro cometas, mas em nosso repositório remoto, temos apenas Não temos esse em. Se quisermos adicionar esse kamide ao repositório remoto, precisamos usar o comando push do Git Agora, como sabemos, esse principal será movido para nosso último kamid também em nosso repositório, origin main também será movido para esse Nós escrevemos isso push. Aqui, temos que escrever o nome do nosso repositório remoto, que é origem Depois disso, queremos empurrar o casaco, que é o principal. Atualmente, também estamos no principal, então podemos remover esse principal e também podemos remover a origem porque esse é o repositório remoto padrão Agora, às vezes, ele pode solicitar seu nome de usuário e senha do Github antes de enviar o código Você tem que escrever quando pedir e pronto. Vamos conferir nosso histórico. Veja aqui nossa origem Min é movida para nosso comando principal. Se quisermos verificar , podemos verificar nossa página do GitHub Veja aqui, obtemos quatro amets e se verificarmos aqui , obtemos Camets Enviamos nosso código com sucesso para nosso repositório remoto. Agora, deixe-me mostrar outra situação. Suponha que aqui temos três gametas e, no repositório remoto, temos apenas dois Agora, antes de enviarmos esse camete para o controle remoto, nosso membro da equipe pressiona outro kamit aqui Se enviarmos nosso código , nosso comando push falhará Você pode me dizer por quê? Certo. Nessa situação, nosso histórico do repositório local e o histórico do repositório remoto são diferentes Se o Git ainda permitir que façamos push , podemos perder o commit desse membro da equipe E é por isso que o Git falha em nosso comando push. Agora, às vezes, muitos desenvolvedores usam o Git push F para forçar nosso código Então, quando executamos esse comando, removemos esse amit e adicionamos nosso amid no remote Mas isso não é uma boa prática porque, basicamente, estamos removendo o trabalho dos membros da nossa equipe. Então, se você não tem nenhum motivo principal, então, na minha sugestão, não use força de pressão. Agora, qual é a solução para isso? Então, se nossa solicitação push falhar , primeiro, fazemos a solicitação pull. Isso adicionará esse gummit em nosso repositório local e, usando merge ou rebase, poderemos adicionar alterações em nosso mid e, em seguida, enviar nossas alterações em seguida, enviar nossas Então, agora nosso repositório local e nosso histórico de repositórios remotos são os mesmos Portanto, os comandos mais úteis para o Git são git pull e Git push porque esses dois comandos são muito usados para trabalhar 73. Encaminhando as tags para o remoto: Agora, suponha que, neste estágio, nosso aplicativo esteja pronto para a versão 1.0. Você se lembra do comando para adicionar tags? Não se preocupe, você pode ver minha folha de bate-papo do Git. Então, aqui escrevemos a versão 1.0 da tag git. Neste comando, adicionamos uma tag ao nosso commit atual. Se quisermos atribuir essa tag a um commit específico , podemos escrever aqui aquele ponteiro ou commit Por enquanto, vamos adicionar uma tag ao nosso último commit. Vamos verificar isso. Registro do Git. Veja, nosso último commit está marcado como tag versão 1.0. Agora, aqui, eu quero te dizer uma coisa. Essa tag só é visível em nosso repositório local. Isso não está visível no repositório remoto do Github. Então, como podemos enviar nossas tags para um repositório remoto? Para isso, temos que escrever git push. Aqui escrevemos nosso nome remoto que é origem. Aqui, escrevemos o nome da nossa tag que queremos inserir, que é pessoa 1.0. Feito. Agora vamos verificar no site do Github se recebemos nossa tag ou não Veja, aqui temos uma etiqueta. Vamos ver isso com mais detalhes. Aqui, podemos ver o nome do autor, hora e também podemos baixar o código-fonte completo aqui. Eu o uso muito quando estou trabalhando em grandes projetos. Então é assim que podemos empurrar a tag. Agora, suponha que queremos remover essa tag, para que possamos escrever o mesmo comando aqui, adicionamos dash delete Veja, ele foi excluído com sucesso. Agora, se verificarmos nosso histórico , veremos que a tag ainda está aqui porque esse comando apenas remove a tag do nosso repositório remoto Se também quisermos remover essa tag do repositório local , escrevemos Get tag, D, escrevemos o nome da tag Veja, ele também foi removido do nosso repositório local. 74. Crie lançamentos para o Github: Então, na lição anterior, vemos como podemos dar etiquetas. Mas aqui está uma coisa sobre tags. Nas tags, não podemos descrever o que está dentro da versão 1.0. Portanto, se um novo desenvolvedor se juntar à nossa equipe , teremos que explicar a ele o que está dentro dessa versão. Caso contrário, temos que pedir a eles que vejam todas as mudanças. Mas não se preocupe, o Github fornece uma solução muito útil para essa situação No Github, podemos adicionar lançamentos para descrever o que está dentro dessa versão Então vamos à seção, e aqui temos os lançamentos. Atualmente, não temos nenhuma versão, então criamos uma nova versão. Agora, na parte superior, temos a opção de selecionar a tag. Atualmente, não temos uma tag porque a excluímos na lição anterior. Aqui, nossa tag nomeia a versão 1.0 e criamos uma nova tag Depois disso, selecionamos uma ramificação, que é principal. Aqui podemos escrever o título do nosso lançamento. Na maioria das vezes, escrevemos o mesmo nome do nosso nome de tag, mas você também pode fornecer seu nome. Depende totalmente de você. Agora, nesta área de texto, podemos descrever nossas mudanças e recursos. Então, primeiro, selecionamos o título daqui e aqui, nosso título, digamos, detalhes do lançamento. Você quer ver uma prévia, então também podemos ver isso. Além disso, temos muitas opções. Vamos adicionar marcadores para obter detalhes. Vamos criar o layout básico do site, corrigir o bug do layout e criar a página inicial Vamos ver a prévia. Veja, nós temos nossos detalhes. Agora, na parte inferior, também podemos anexar arquivos binários a esta versão. Se você tiver uma versão compilada do seu aplicativo ou de qualquer arquivo binário que queira adicionar , edite aqui. Se sua versão não estiver pronta para publicação , podemos verificar essa versão como pré-lançamento. Os membros da equipe sabem que isso não está pronto para produção. Agora, vamos supor que estamos prontos para o lançamento. Eu desmarco essa caixa e clico em publicar. Veja aqui que obtemos nosso novo lançamento e podemos ver detalhes, algumas informações básicas e, como nosso texto, também obtemos aqui nosso código-fonte. O lançamento é um recurso muito bonito para trabalhar em equipe, e também podemos usá-lo como documentação de nossa jornada de aplicação. Se formos para a página inicial , no lado direito, obteremos todas as versões desse repositório Então, uma coisa que eu quero dizer é que o lançamento é o recurso do Github, não do Git Só podemos ver lançamentos usando o Github, não pela linha de comando Agora, na próxima lição, veremos como trabalhar com filial em equipe? 75. Trabalhando com filiais: Agora vamos ver como você pode trabalhar com filiais em equipe. Aqui, eu crio uma nova ramificação com kit switch C feature slash ad to cart Agora vamos verificar nossa lista de filiais. C. Aqui temos duas filiais, principal e Adicionar ao carrinho. Mas essa nova filial só está disponível no ambiente local. Agora, se os membros da nossa equipe quiserem trabalhar na mesma filial , como eles podem fazer isso? Para isso, temos que enviar essa ramificação para nosso repositório remoto Ou empurrando o que usamos, certo. Usamos git push origin mean para enviar alterações para a origem Mas aqui temos tudo atualizado porque esse comando só envia códigos para o controle remoto, não para filiais. Escrevemos aqui, gate, push, aqui temos esse erro de pétala, que diz que o recurso de ramificação atual, slash head to card, não tem ramificação ascendente Também está nos dando sugestões para resolver esse erro. Esse comando definirá essa ramificação upstream na origem do nosso repositório remoto Mas espere, o que é essa filial a montante? O que acontecerá se configurarmos a filial upstream? Configurar a ramificação upstream significa criar uma conexão entre nossa filial local e uma ramificação no repositório remoto Deixe-me explicar com o exemplo. Atualmente, essa é nossa filial em nosso repositório local. Se atualizarmos nossa ramificação, isso significa que criamos uma conexão com, digamos, uma ramificação chamada Origin slash feature slash slash Ed to card Não se preocupe, isso é só por exemplo. Se você empurrar seu galho , ele terá o mesmo nome que você deu a ele. Agora, essas duas ramificações estão conectadas entre si e também podemos dizer que a ramificação upstream, também conhecida como ramificação de rastreamento remoto Você pode dizer que entendemos que configurar a ramificação upstream é criar uma conexão entre local e uma ramificação no repositório remoto Mas por que precisamos dessa conexão? Qual é o benefício de fazer isso? O primeiro benefício ao configurar a ramificação upstream é que o Git sabe onde publicar as alterações da ramificação local Portanto, se enviarmos as alterações da ramificação local , por meio dessa conexão, saiba onde essas alterações serão adicionadas ao repositório remoto e também se aplicará à extração das Se um membro da nossa equipe enviar algo para essa ramificação , se retirarmos essas alterações, saberemos de onde ele precisa buscá-las Portanto, ele buscará as alterações desse recurso de barra de origem de ramificação remota, barra e adição ao cartão em nossa No geral, ao configurar a ramificação upstream, nosso fluxo de trabalho é fácil de enviar e extrair alterações entre o repositório local e o remoto Vamos ver como podemos configurar filial upstream para nossa filial local E aqui, o Git também nos dá uma solução. Antes disso, vamos ver nossas filiais atuais de rastreamento local e remoto. Basicamente, vemos o nome da ramificação upstream. Ramificação Git, V C, aqui temos Min e sua ramificação upstream é origin main Mas, no que diz respeito aos recursos diretos, não temos nenhuma filial upstream ou podemos dizer que não temos uma filial de rastreamento remoto Se quisermos ver a lista de ramificações de rastreamento remoto , também podemos ter um comando para isso. Git branch R para rastreamento remoto. Veja, atualmente, temos apenas esses dois ponteiros origin main e origin slash head Vamos configurar a ramificação upstream ou a ramificação de rastreamento remoto usando git push, dat, upstream, ou aqui, podemos escrever atalho que é dU ou upstream, aqui escrevemos nosso E depois disso, escrevemos o nome da nossa filial local, que é feature slash head to cart Lembre-se de que precisamos escrever esse comando somente na primeira vez que pressionarmos nossa ramificação. C, o galho é empurrado. Agora, se verificarmos nossas filiais a montante, pegue a ramificação V C. Agora, aqui podemos ver a ramificação ascendente da nossa filial local, que é o recurso de origem, corte da cabeça para que é o recurso de origem, corte da cabeça Além disso, se executarmos o comando git branch R, C, o branch de rastreamento remoto será adicionado Também vamos verificar isso no GitHub. Basicamente, temos uma ramificação, atualize a página e veja, aqui temos duas ramificações Agora podemos começar a trabalhar nessa filial direta, da mesma forma que estamos trabalhando em nossa filial principal. Quando quisermos ampliar nossos gammas , podemos aplicá-los a essa ramificação e outros membros da equipe podem ver essas mudanças Se quisermos remover esse link entre a ramificação local e a ramificação de rastreamento remoto , podemos escrever um comando como esse pressionar D para exclusão. Aqui escrevemos nosso nome remoto, que é origem. Em seguida, escrevemos o nome da nossa filial , que é a barra característica da cabeça ao cartão Então, agora removemos a ramificação de rastreamento remoto. Se executarmos git branch, R, depois C, novamente, obteremos esses dois ponteiros E se executarmos git branch, VV , aqui podemos ver recurso de origem slash head to card Também vamos remover essa ramificação do nosso repositório local. Para fazer isso, primeiro precisamos voltar para a filial principal. Aqui escrevemos o branch D do Git, e aqui escrevemos recurso do nome do branch slash t no card e pronto, é assim que podemos publicar o branch em nosso repositório remoto configurando Agora, na próxima lição, entenderemos no mundo real como os membros da equipe trabalham com a filial. 76. Cenário do mundo real para trabalhar com o Branch: Vamos entender como trabalhar com filiais usando o cenário do mundo real, você pode entender com mais clareza sem perder tempo Este não é o exemplo, é uma história real. Quando entrei na minha primeira empresa, tive a oportunidade de trabalhar em um recurso, que é trabalhar no design da página inicial Neste recurso, eu tenho que trabalhar com Unati e ela é a funcionária atual dessa empresa Temos que criar a página inicial do site da empresa. Essa empresa estava criando um site como stackoverflow para problemas Ela me disse que trabalha no design do cartão de perguntas e que eu tenho que trabalhar na seção de cabeçalho, rodapé e barra lateral Em primeiro lugar, ela criou uma nova filial chamada feature Ss Home Page e começou a trabalhar no design do cartão Qi. Mas aqui estou sem noção. O que está acontecendo aqui? Como posso trabalhar com a filial? Eu sei o básico do git, mas não tenho experiência real Primeiro clono o projeto do Github e, primeiro, executo o pull request para obter as alterações mais recentes do repositório remoto Também começo a trabalhar no mesmo recurso da ramificação da página inicial do Sless Nós dois estamos trabalhando de forma independente na mesma filial. Agora ela concluiu seu design, então ela se compromete com o código e, em seguida, envia as alterações para o repositório remoto Agora ela me diz que inseriu o código. Aqui, novamente, retiro a solicitação, obtenho as alterações mais recentes e as mesclo com meu código Agora, depois de algum tempo, estou pronto com meus designs, então eu insisto nas alterações e informo a ela. Ela executa o git pull request e o mescla com seu código. Após 5 horas fazendo isso de puxar e empurrar, terminamos o design da página inicial Finalmente, eu insisto em todas as mudanças e digo a ela. Ela faz todas as mudanças na filial e, se tiver conflitos, entramos em contato um com o outro e resolvemos o problema. Agora, esse código é testado e nosso gerente revisa o código final. Se tudo bem, então esse código se mescla na ramificação principal ou rebase ou squash kms, Em seguida, esse recurso reduz a ramificação da página inicial do controle remoto À medida que removemos a ramificação do repositório local. Esse é o cenário de trabalhar juntos, ou você pode ver como podemos trabalhar na mesma filial da equipe. 77. Mostra prática de trabalho com filial: Vamos ver a vitrine prática de trabalhar com filiais Você pode perguntar por que estou tão focado em trabalhar com filiais? Porque esse é o conceito mais usado e pouco confuso para desenvolvedores, e é por isso que estou mostrando passo a passo Depois de concluir este curso, você domina o trabalho com filiais. Para simular isso, vou mostrar a vocês dois trabalhos do BC. Eu trabalho no meu PC e também compartilharei a tela do meu PC Este é o Nats PC. Agora, aqui neste projeto, C cria uma nova ramificação. Anteriormente, vimos como criar ramificações usando comandos, mas também podemos criar ramificações usando o Github. Ou abra essa ramificação, suspensa e, a partir daqui, podemos criar uma nova ramificação. Digamos que projete a página inicial e selecione, crie uma ramificação a partir da página principal e pronto Criamos nossa nova filial e vemos aqui que essa filial está atualizada com a principal A ramificação está no repositório remoto. Precisamos buscá-lo em nosso repositório local. Então, aqui neste terminal, escrevemos git fetch para buscar essa ramificação. Veja, aqui temos a nova página inicial do branch design slash. Agora deixe-me te mostrar uma coisa. Se escrevermos a ramificação do Git, veja, aqui não obtemos a nova ramificação, mas podemos ver o Git encontrar essa ramificação em nosso repositório remoto Aqui, escrevemos a ramificação Git R. Então temos essa ramificação de rastreamento remoto Quando executamos o Git fetch , sempre obtemos a ramificação de rastreamento remoto Agora, criamos uma nova ramificação privada em nosso repositório local e a vinculamos à ramificação de rastreamento remoto Para isso, escrevemos switch, C ou create aqui escrevemos o nome da nossa filial local, quisermos chamar. Podemos chamá-lo de qualquer coisa, mas na maioria das vezes, chamamos isso da mesma forma que o nome da agência de rastreamento remoto. Portanto, não precisamos nos lembrar disso. Página inicial de design. Depois disso, temos que escrever o nome da nossa filial de rastreamento remoto, que queremos vincular, que é a página inicial do Origin Design Recebemos o nome da agência de rastreamento remoto aqui. Agora, se escrevermos git branch VV, C, aqui obtemos a ramificação, que também está vinculada à página inicial da barra de design original Quando outra pessoa cria uma ramificação e envia uma ramificação para o repositório , primeiro precisamos executar o comando fetch Com isso, obtemos a ramificação de rastreamento remoto e, em seguida, temos que criar uma ramificação local e vinculá-la à nossa ramificação de rastreamento remoto usando Kit Switch, C, nome da filial local e nome da ramificação de rastreamento remoto. Agora, aqui podemos confirmar nossas mudanças e levá-las à nossa origem. Então eu abro esse repositório no código VS, e aqui eu crio um novo arquivo chamado index dot DML, e apenas adiciono aqui o código padrão . Salve isso e simplesmente organize as alterações e confirme essas alterações. Gated M, crie e indexe pontos DML para a página inicial. Vamos também enviar as alterações para o controle remoto. Git Push, pronto. Agora vamos ver como eu trabalho na minha tela. Aqui temos nosso repositório no meu PC. Se não tivermos, teremos que clonar nosso projeto. Vamos primeiro ver todas as mudanças usando git fetch. Se verificarmos nosso registro, veja, aqui temos uma nova filial. Agora eu mudo para essa ramificação usando página inicial do Kit switch Design slash Agora, antes de começarmos a trabalhar em nosso código, é sempre melhor extrair as alterações do controle remoto. Mas aqui nós apenas buscamos as alterações para que não precisemos delas, para que possamos começar a trabalhar diretamente nisso Aqui eu faço algumas alterações no arquivo script dot js, salvo as alterações. Agora vamos imaginar que eu concluí meu trabalho nessa filial. Vamos preparar as alterações e também confirmar o código com a mensagem de confirmação, concluir o trabalho no arquivo script js, eu envio as alterações, Gate push. Agora, como eu disse anteriormente, fechar esta filial é responsabilidade da Nati Vamos voltar às especificações nati. Aqui, veja primeiro, importe minhas alterações usando o Git pull. Bom. Aqui, agilizamos nossa fusão. Vamos conferir nosso histórico. Aqui chegamos aos compromissos. Agora temos nosso código de ramificação pronto e também nosso ponteiro de design da página inicial está à frente da ramificação principal Aqui, temos que mesclar nosso código na ramificação principal. Já fizemos isso tantas vezes, aqui, primeiro voltamos para a filial principal. Depois disso, escrevemos gate, mesclamos, projetamos a página inicial Veja, aqui nós agilizamos nossa fusão porque temos ramificações lineares Mas aqui não temos conflitos. Porque isso é apenas uma demonstração. Provavelmente, toda vez que você tiver conflitos, já sabemos como resolvê-los. Portanto, você precisa resolver isso com os membros da sua equipe. Agora, vamos ver aqui nosso registro. Agora podemos ver nosso ponteiro principal e o ponteiro da página inicial de design no Mas a origem de Min está no meio anterior. Então, temos que enviar as mudanças no repositório remoto e como podemos fazer isso, certo, usando o Git Agora vamos verificar nosso histórico novamente. Agora, origin Min está na mesma marcha. Agora vamos verificar isso também no Github. Vá até os gametas. Veja aqui nosso mais recente Camite, que é o Merge Gamit Agora que nossa ramificação de design da página inicial está mesclada na ramificação principal, podemos remover essa ramificação da página inicial de design Caso contrário, isso criará confusão. Portanto, obtenha a página inicial de origem e design do ph D. C, ramificação excluída do repositório remoto. Mas se virmos as ramificações, C, aqui ainda temos a ramificação da página inicial, então também temos que descartá-la Obtenha a página inicial de design da filial D. Agora, nossa filial local também está encerrada. Agora, de volta ao meu PC, primeiro, farei as alterações para obter a confirmação da mesclagem Agora nós dois temos o mesmo histórico de confirmações. Primeiro, vamos verificar a ramificação de rastreamento remoto usando o Git BanchR Veja aqui que estou recebendo o design original slash home branch. Até agora, removendo a ramificação de rastreamento remoto, que não está disponível no controle remoto, escrevemos o Git remote Prune origin Esse comando removerá todas as ramificações de rastreamento remoto que não estão disponíveis no repositório remoto Agora deixe-me verificar as agências locais. Veja, eu ainda tenho aqui, eu também tenho que abandonar a filial local. Novamente, a página inicial do git branch D Design, e aqui temos um erro, não pode excluir a página inicial do branch design slash porque atualmente estamos na página inicial do Design slash, mudamos para a Porta como usar o comando git pull para atualizar a ramificação local Veja aqui, agilizamos nossa fusão e, se verificarmos nosso histórico, veja aqui, ainda temos essa ramificação de design da página inicial Executamos a página inicial do git branch D Design slash e excluímos a É assim que trabalhamos com filiais em equipe. Você fica um pouco confuso, então não se preocupe, deixe-me recapitular essa parte Primeiro, criamos uma nova ramificação e, em seguida, para empurrar essa ramificação, temos que configurar a ramificação a montante Portanto, ele sabe qual filial local está conectada à filial remota. Depois disso, podemos começar a trabalhar na filial. Se quisermos enviar algo, primeiro comprometemos isso e depois podemos enviá-lo para a origem. Mas antes de empurrar, é uma boa prática usar o pull. Recebemos as alterações mais recentes e, após concluir o trabalho da ramificação de commits, mesclamos com a ramificação principal e, em seguida, removemos a ramificação de rastreamento remoto e também a ramificação local Se a ramificação de rastreamento remoto já tiver sido abandonada por outro membro da equipe , teremos que executar git remote, Prune origin e pronto 78. Criando solicitações de pull no Github: Agora, suponha que você esteja trabalhando em uma ramificação e, no meio do código, queira receber algumas sugestões dos membros da equipe. Em seguida, no Github, você pode receber sugestões ou abrir uma discussão sobre o tópico específico Nessa situação, podemos criar um pull request para abrir uma discussão sobre nosso código Peça sugestões ou avaliações de outros membros da equipe. Deixe-me mostrar isso na prática. Aqui está o NathiPC. Vamos criar uma nova ramificação e fazer alterações nessa ramificação. Primeiro, escrevemos a página de perguntas e respostas do Git switch Design slash. Vamos abrir esse código no código de vias. Aqui no ponto de índice SDMLFle no corpo, eu adiciono a tag principal Dentro disso, eu adiciono Du, outro DU e aqui H uma tag. Essa é a primeira pergunta. Isso é só uma demonstração. Salve isso e vamos entrar em contato e publicar essas alterações. Em nosso terminal, escrevemos corretamente AM, adicionando um cartão Q. Um. Bom. Agora, precisamos enviar essas alterações para nosso repositório remoto E como podemos fazer isso? Podemos escrever Gate, Push. Mas veja aqui que temos um erro fatal. Você pode me dizer por quê? Sim, porque não configuramos a filial upstream Ou, em palavras simples, não vinculamos nossa filial local à filial remota. Aqui, simplesmente escrevemos Git push u origin, aqui escrevemos o nome da nossa filial local, que é a página de perguntas e respostas do Design Slash Aqui, promovemos nossas alterações com a configuração da ramificação Upstream. Deixe-me abrir essa conta no site do GitHub. Veja na página inicial, aqui temos Design SQ e página, H DSN push, e também recebemos D compare e Aqui, podemos abrir uma discussão para esta ramificação da página de perguntas e respostas e colaborador pode dar algumas sugestões ou discutir Além disso, podemos criar pull request a partir dessa guia Pull Request. Clique em New Pull Request. Agora, aqui, podemos selecionar duas ramificações para comparar as alterações. Na maioria das vezes, selecionamos a ramificação principal como ramificação base e aqui selecionamos nossa ramificação da página de perguntas e respostas Veja, aqui temos os commits nesta filial. Temos um commit, uma alteração de arquivo e também temos um colaborador Aqui temos uma lista de commits e, abaixo disso, podemos ver as alterações em nossos arquivos Aqui também podemos selecionar a visualização dividida, para que possamos ver o antes e o depois com muita clareza. Agora vamos abrir a discussão sobre esse ramo. Clique em Criar Pull Request. Aqui podemos escrever o título da nossa discussão. Vamos mudar essas duas sugestões para um telefone com cartão de perguntas. Abaixo disso, podemos descrever o que queremos discutir, o que queremos corrigir, etc Digamos que primeiro adicionemos sugestões de títulos necessárias e, depois disso, marcadores, sugerimos algumas tags semânticas para o cartão e apresentamos uma visão geral desse código corporal Agora podemos simplesmente criar um pull request ou também podemos redigi-lo. Vamos para Criar pull request. Veja aqui que estamos na conversa e esse status de pull request está aberto. Agora, como outros membros da equipe podem saber que abrimos essa discussão? Para isso, temos que adicioná-los aos revisores. Clique neste ícone de engrenagem e aqui temos a lista de colaboradores, que adicionamos em nosso repositório no início desta seção Nós gostamos dessa conta. Agora, no momento em que selecionamos o usuário, Github envia um e-mail para esse usuário informando que ele tem uma nova discussão Agora, deixe-me mudar a janela e mostrar como esse membro da equipe pode revisar nosso código. Então esta é minha conta original. Vamos até o pull request e vemos aqui que temos essa discussão. Abra isso. Veja na parte superior, aqui recebemos essa mensagem. Esse usuário solicitou sua avaliação sobre esse pull request. Então clique em adicionar seu comentário. Aqui, temos uma visão dividida desse arquivo alterado. Se você quiser ver o arquivo inteiro, podemos clicar aqui, Expandir tudo. Agora, aqui, eu tenho algumas mudanças que eu gostaria de sugerir. Primeiro, nesta tag principal, podemos usar o artigo da seção e, em seguida, H uma tag, não a simples de Também quero contar na aula para o artigo do cartão de perguntas para os desenvolvedores saibam que esse é o cartão de perguntas. Aqui podemos ver antes de cada linha, obtemos esses ícones de adição. Com isso, podemos escrever uma resenha para cada linha. Mas, atualmente, eu só quero dizer a hierarquia do texto e o nome da classe Então, clico nesse ícone de adição e escrevemos nossa análise aqui. Então, eu adiciono o marcador primeiro, adiciono a tag semântica, a seção principal, o artigo H um e, depois disso, adiciono classe igual ao cartão de sublinhado da pergunta à cartão de sublinhado da pergunta E simplesmente comece a revisão. Veja aqui que podemos ver a análise e os detalhes e, atualmente, ela está em estado pendente, e simplesmente concluímos essa análise. Aqui, temos que escrever uma descrição básica para nossa análise. Então, podemos escrever essas são as sugestões para esse código, fazer as alterações e enviá-las. Agora, na parte inferior, temos três opções. Primeiro, podemos enviar isso como comando. Podemos definir a aprovação e solicitar as alterações. Atualmente, estamos solicitando duas alterações, para que possamos selecioná-las e simplesmente enviar a avaliação Veja, estamos na guia de conversa desse pull request e, a partir daqui, podemos ver o que está acontecendo aqui na parte inferior, recebemos nossa análise, que acaba de ser enviada de forma muito sistemática. E abaixo disso, você pode ver que temos uma solicitação de alterações. No lado direito, temos esse ícone, que informa esse usuário sobre a solicitação de alterações Então, agora vamos mudar novamente para a conta nadis a partir da qual iniciei essa discussão Primeiro, fizemos a pré-visualização na guia de conversa. E então fazemos alterações em nosso código. Então eu abro o ponto de índice SDMLFle. Primeiro, eu altero isso primeiro devido à seção e segundo DU para o artigo. Se você quer saber como estou alterando as tags de abertura e fechamento juntas, então você deve instalar a extensão Autor nam tag em seu código VS, altamente recomendada Além disso, precisamos adicionar aqui a classe ao cartão de sublinhado da pergunta Salve as alterações e vamos confirmá-las. Então, tags semânticas GTMTam e atualização do nome da classe Eu sei que essa é uma mensagem de confirmação ruim, mas é só para demonstração Então, vamos também insistir nisso. Agora, ao concluirmos nossas alterações, precisamos pedir a esse membro que veja nossas alterações e as verifique. No lado direito, temos essa opção de nova solicitação de revisão. Clique nisso. Isso enviará novamente um e-mail para esse usuário e solicitará que ele veja as atualizações. Eu mudo novamente para minha conta e aqui posso ver esse usuário solicitou sua avaliação sobre esse pull request. Clique em adicionar sua avaliação. Verifique nossas alterações e, se não estivermos satisfeitos, poderemos novamente escrever uma avaliação e enviá-la. Aqui, estamos satisfeitos com as alterações, então podemos clicar em visualizadas e simplesmente clicar nessas alterações de revisão. Aqui, eu escrevo, perfeito, que está mesclado em nosso ramo principal Na parte inferior, podemos selecionar, aprovar e enviar avaliações Veja aqui que as alterações são aprovadas, e essa discussão cumpre seu propósito. Podemos ver, na parte superior, que temos o status de alterações aprovadas. Agora, na parte inferior, temos opções para mesclar essa solicitação de pool Agora, aqui está um debate sobre o que os desenvolvedores fazem quando se trata de fechar uma solicitação de pool. Pergunte quem deve mesclar esse pull request? Quem iniciou o pull request ou alguns revisores devem mesclar o pull request Alguns desenvolvedores optam por essa primeira opção porque acham que a pessoa que inicia o pull request sabe mais sobre isso. Então, ele ou ela que criou esse pull request precisa mesclá-lo Portanto, alguns desenvolvedores dizem que a pessoa que contribui para o MR é o revisor; o revisor deve Honestamente, você não precisa se preocupar com isso. Basta perguntar aos membros da equipe ou ao gerente sobre isso, porque algumas empresas seguem primeira opção e outras seguem a segunda. Então, faça o que os membros da sua equipe sugerem. Podemos mesclar essa solicitação de pull a partir daqui e temos três opções para mesclagem, mesclagem simples, squash and merge e rebase e mesclagem daqui e temos três opções para mesclagem, mesclagem simples, squash and merge e rebase e mesclagem. Já conhecemos essa opção, então vamos fazer uma mesclagem simples, confirme a fusão Veja, recebemos a solicitação de pull mesclada e fechada com sucesso. Agora podemos remover esse galho daqui. Podemos restaurar o galho. Agora, deixe-me ir até o NathipCF voltar para o portão principal, puxar para obter a confirmação da Veja, agilizamos nossa fusão e, se verificarmos nosso histórico, veja, aqui temos página de perguntas e respostas e também a filial de rastreamento remoto necessário remover essa ramificação do local e também remover a ramificação de rastreamento remoto. Portanto, essa ramificação já foi removida do repositório remoto e queremos removê-la do nosso repositório local e saber como podemos fazer isso Podemos escrever git remote, prune origin. Agora vamos remover essa ramificação local também. Git branch D, página de perguntas e respostas do Designs e pronto. Você pode ver se usamos algum comando do Git duas ou três vezes, então não nos confundimos com isso Como eu disse, isso é tudo uma questão de prática. Eu sei que esta lição é um pouco longa, então você pode fazer uma pausa de cinco a 10 minutos, tomar um pouco de ar fresco e depois continuar este curso. 79. Resolvendo conflitos durante pull requests: Anteriormente, vimos que quando estamos fazendo uma mesclagem em pull request, não temos nenhum conflito Mas e se tivermos um conflito? Uma maneira é usar o código VS, mas isso é um pouco longo. Se estivermos fazendo a fusão em nossa filial local, teremos que usar o código VS Mas também podemos resolver conflitos usando o Github. Só é útil quando estamos mesclando o pull request. Digamos isso. Primeiro, eu crio uma nova ramificação a partir de Una neste PC e faço uma marcha e empurro aquela Kat Obtenha a página inicial dos recursos do swish C. Aqui no ponto de índice SDMLFle, eu mudo o título da demonstração para o título da página inicial E também altere a primeira linha no arquivo script dot Gs. Este é um script para a página inicial. Salve as alterações e vamos confirmar esse recurso Gtms AM, atualize o título e o script para o recurso inicial Agora, vamos colocar essa ramificação no Github. Você se lembra disso? Certo, use o Git push para configurar Slash, recurso de origem da ramificação Upstream Feito agora para criar conflito, abro uma conta do Github no meu PC e simplesmente abro ponto de índice STMLFle, selecionamos Editar e alteramos esse título para título na Vamos confirmar as alterações e continuar com essa confirmação. Agora vamos criar mais um arquivo js inscript de conflito. Então, mudamos novamente a primeira linha do script por ramificação principal e chegamos aos intercâmbios Agora, deixe-me criar um pull request. Então vá para o Github e vamos para a seção de pull request Aqui, criamos uma nova pull request. Base é a ramificação principal e a comparamos com a página inicial do recurso SLS Veja, aqui não podemos mesclar automaticamente. Não se preocupe, você ainda pode criar uma pull request. Vamos criar uma pull request. Aqui, ele escolhe automaticamente a mensagem de confirmação, e podemos escrever uma descrição para a pull request, pull request para a página inicial da barra de recursos e criar uma pull request Veja, aqui está que essa filial tem conflitos que devem ser resolvidos. Então, aqui podemos usar a linha de comando para resolver os conflitos. Além disso, podemos fazer isso usando o Github. Simplesmente clicamos em Resolver conflitos. Aqui no lado esquerdo, obtemos a lista de arquivos que têm conflitos. Aqui podemos ver o conflito. Já vimos essas dicas. Quero manter o título desta página inicial. Se o conflito foi removido desse arquivo e clique em Marcar como resolvido para este arquivo. Agora, para o próximo arquivo, aqui eu mantenho esse código de ramificação principal. Veja aqui se todos os conflitos desapareceram. Também podemos marcar esse arquivo como resolvido e simplesmente confirmar a mesclagem. E veja, agora essa ramificação não tem conflito com a ramificação base. Além disso, se você quiser adicionar revisores , também podemos fazer isso, mesma forma que fizemos na lição anterior Agora podemos mesclar o pull request e confirmar a mesclagem. É assim que podemos resolver conflitos ao criar uma solicitação de mesclagem 80. Criando problemas no Github: Agora, no Github, como temos o recurso de pull request, também temos a opção de problemas Novamente, esse é o recurso do Github, não do Git. Quais são esses problemas? Os problemas são como nós adesivos que usamos em nosso livro. Os nós fixos são usados para escrever nós, corrigir algo ou escrever perguntas, etc Da mesma forma que podemos usar problemas para rastrear tarefas, bugs ou também podemos discutir sobre nosso projeto. Deixe-me te mostrar isso. Então clique em Nova edição. Aqui, podemos escrever o título da nossa edição. Digamos, uma discussão sobre os recursos do cartão. E aqui escrevemos nossa descrição para esse problema. Vamos discutir sobre os recursos do cartão de perguntas para este projeto. Aqui também podemos atestar a imagem de demonstração do design básico do nosso cartão Os anexos são muito úteis. Se estivermos criando problemas para resolver os bugs , podemos atestar a captura de tela ou a gravação da tela para mostrar os No lado direito, podemos atribuir o problema aos membros da nossa equipe. Por enquanto, acabei de adicionar minha outra conta. Depois disso, temos rótulos. Github tem muitos rótulos relevantes para quase todos os tipos de problemas Veja aqui que obtemos documentação de bug, duplicata, aprimoramento, bom primeiro problema, inválido, pergunta e Além disso, podemos criar nossos próprios rótulos. Vamos editar esses rótulos. E crie uma nova etiqueta. Podemos dar uma discussão sobre nomes. A partir daqui, podemos mudar de cor. Então, deixe-me tentar algo. Sim. Eu gosto desse e crio uma etiqueta. Agora, de volta à nossa página. E eu seleciono esse novo rótulo. Aqui também podemos vincular nossos projetos. Além disso, atualmente, não temos marcos. Veremos marcos na próxima lição. Por enquanto, não se preocupe com isso. Além disso, atualmente, não temos pull request, caso contrário, também podemos conectar o problema com o pull request. E quando mesclarmos esse pull request , todos os problemas conectados serão fechados automaticamente e enviaremos um novo problema Veja aqui que abrimos esse problema. Agora, os responsáveis comentarão sobre esse assunto discutirão sobre o que pensam e apresentarão suas sugestões Agora, depois de concluir toda a discussão, também podemos encerrar esse problema. É assim que podemos usar problemas usando o Github. É por isso que os desenvolvedores adoram o Github. 81. Adicionando marcos no GitHub: Agora, às vezes, em nosso projeto, queremos criar um marco Marco, podemos ver como a meta de curto prazo ou a meta de longo prazo, que queremos concluir em um determinado momento Por exemplo, em nosso projeto, queremos adicionar o recurso de autenticação do usuário. Assim, podemos criar um marco e definir uma data para concluir esse marco Nesse marco, podemos adicionar vários tipos de problemas, como página de login de design, página inscrição de design, plano opções de redefinição de senha etc Suponha que eu conclua esse problema da página de login de design, para que eu possa marcar esse problema como encerrado e, em nosso marco, obtenhamos 33,3% Quando todos os problemas são resolvidos estão conectados a esse marco , nosso marco flui automaticamente Isso é muito útil para planejar, organizar e acompanhar o progresso de nossos projetos. Vamos ver como podemos criar um marco no Github. Aqui estamos na seção de questões. No topo, temos a opção de marco. Atualmente, não temos nenhum marco, crie um novo Aqui, eu escrevo o título para esse marco. Digamos que a autenticação do usuário. Aqui, podemos selecionar o valor aproximado quando concluirmos esse marco e, finalmente, podemos escrever descrição para descrever Portanto, implemente a funcionalidade de autenticação do usuário, incluindo recursos de login de inscrição e redefinição de senha, e criaremos um marco Esta é a nossa lista de marcos. Aqui temos detalhes básicos sobre o marco e aqui podemos ver nosso progresso Agora, para mostrar seu progresso, vamos adicionar um problema nesse marco Vá até os problemas e crie novos problemas. Adicione aqui o título, o design, página de login, adicione o responsável para que também possamos atribuir a nós Eu seleciono o rótulo para aprimoramento e, a partir daqui, podemos selecionar o marco Veja, aqui temos o marco da autenticação do usuário. Essa é outra forma de adicionar problemas no marco. Então, por enquanto, acabei de enviar uma nova edição. Agora, volte para a página de edições. Aqui, selecionamos nossos problemas entre todos os problemas abertos. E aqui temos a opção de marco. Aqui, selecionamos o marco de autenticação do usuário e, aqui, obtemos o nome do nosso marco Vamos ver nosso marco. Podemos ver que temos um problema em aberto neste marco. Então, clique no marco e depois de concluir o problema, podemos selecioná-lo e marcá-lo como problema encerrado E veja aqui que nosso marco está 100% concluído. É assim que podemos usar marcos no Github. 82. Fluxo de trabalho de trabalho em projeto de código aberto: Até agora, vemos como podemos trabalhar em nosso projeto com os membros da nossa equipe. No Gitub, também podemos trabalhar em projetos de código aberto. Vamos ver o fluxo de trabalho do projeto de código aberto. Por exemplo, aqui está um projeto de código aberto no qual você gostaria de contribuir. Este é o projeto na minha conta do Gitub, mas você não pode começar a trabalhar diretamente neste projeto porque não foi adicionado como colaborador, e é por isso que você também não pode enviar seu código Então, qual é a solução aqui? Como podemos começar a trabalhar nesse projeto? Primeiro, você precisa adicionar esse projeto em sua própria conta do Github Isso é chamado de criação de Fork. Agora, aqui temos acesso completo a esse repositório. Agora, quando você terminar sua contribuição, poderá enviar suas alterações para o seu repositório Depois disso, você pode criar uma pull request para mesclar seu código E no momento em que você cria um pull request, Github, me mande um e-mail com isso Alguém criou um pull request para esse projeto de código aberto. Eu verifico seu código. Se eu quiser lhe dar algumas sugestões, eu lhe darei e quando estiver satisfeito com o código, posso mesclar esse código no meu projeto diretamente da sua solicitação de pool Aqui, você não pode mesclar as alterações no meu repositório porque somente eu posso enviar as alterações para o meu projeto Para resumir, primeiro, encontramos um projeto de código aberto no qual você gosta de trabalhar Em seguida, bifurcamos esse repositório. Isso adicionará esse projeto de código aberto sua conta do Github Quando você terminar suas alterações, poderá enviar as alterações em seu projeto para revisão final criar uma pull request. Agora, o autor dessa solicitação verifica seu código, dá algumas avaliações sobre seu código ou sugere que você faça algumas alterações e, em seguida, simplesmente mescle esse código em seu projeto de código aberto É assim que podemos trabalhar no projeto de código aberto. Agora, na próxima lição, veremos isso na prática. 83. Como trabalhar em um projeto de código aberto: Então, quando quisermos contribuir em algum projeto, você pode pesquisar aqui no repositório Suponha que eu queira trabalhar na funcionalidade de pesquisa no react. Então eu procuro aqui react search. Aqui, obtemos a lista de repositórios, e é assim que podemos encontrar o repositório E nesse repositório, os desenvolvedores adicionaram algumas questões que abriram para discussão ou contribuição Você pode trabalhar nesse problema específico. Aqui, seleciono meu próprio projeto, que criei há três anos. E aqui podemos ver que eu também abro uma edição para este repositório. Agora, este repositório é confirmado pela minha conta antiga, não pela conta de Deus, Deus te abençoe. E neste navegador, eu entrei com Cod blessu para poder contribuir Agora, o primeiro passo para trabalhar em projeto de código aberto é bifurcar o repositório em nossa conta Então, no lado direito, basta clicar nesse ícone de neblina. Aqui, podemos alterar esses detalhes, se quisermos , e simplesmente clicar em criar neblina Veja, aqui temos a cópia desse repositório e podemos vê-la embaçada do repositório original Aqui podemos ver que essa ramificação está atualizada com nossa ramificação original do repositório Agora podemos fechar esse repositório em nossa máquina e começar a trabalhar nele Deixe-me mostrar isso para que você não se confunda. Copie o link deste repositório e abra o terminal onde você deseja adicionar este projeto Aqui, escrevemos o Git clone e colamos o link do repositório. Bom. Vamos entrar nessa pasta e criar uma nova ramificação aqui. Obtenha switch como C design Home e abra-o no código VS. Aqui, eu faço uma pequena alteração no arquivo JS do app dot. Salve as alterações e vamos confirmá-las. Então Git, às 8:00 da manhã, atualize o arquivo F. E para promover essa ramificação, primeira vez que escrevemos Git push U para upstream origin Bom. Agora, quando terminamos nossas atualizações, voltamos ao nosso repositório e atualizamos a Veja, aqui temos essa casa de design Harris and push. Assim, podemos comparar e receber solicitações, da mesma forma que antes. Mas aqui está uma pequena diferença. Estamos comparando nossa ramificação inicial de design do nosso repositório fog e comparamos com essa repositório original Aqui, podemos escrever um título para o pull request e também podemos escrever uma descrição. Por enquanto, eu seleciono diretamente criar pull request. Veja, aqui criamos uma solicitação de pool e, nisso, não temos conflitos. Mas aqui está uma coisa. Não podemos mesclar essa solicitação de pool, somente o mantenedor ou proprietário pode Portanto, na minha conta antiga, posso aceitar as alterações e implementá-las nesse repositório principal Aqui está minha conta antiga, que é a proprietária desse repositório, e aqui podemos ver o pull request Abra isso e aqui podemos ver esse berço de baixo, ver aqui esta conta, obter merge, pull request, então mescle pull request e confirme merge Essa alteração é adicionada ao repositório principal. É assim que contribuímos para o projeto de código aberto. 84. Sincronizar Local e Fork com o repositório base: Quando bifurcamos um repositório, esse repositório fog não está realmente conectado ao repositório realmente conectado ao Então, quando estamos trabalhando nesse repositório fog nesse repositório base, alguém pode confirmar alguém pode Então, nesse momento, temos que sincronizar o fog com esse repositório base Mas como podemos fazer isso? É muito simples. Então vamos para o repositório fog. Veja, aqui estamos vendo que essa ramificação está duas ramificações atrás da ramificação do repositório base, o que significa que duas ocorrências acontecem após nosso código atual Então, no lado direito, temos a opção sync fog. Aqui, podemos comparar essas mudanças ou simplesmente atualizar a ramificação. Então, temos uma filial atualizada aqui. Assim, podemos simplesmente buscá-lo em nosso repositório local. Então execute git, fetch. Veja, aqui temos um novo commit. Agora podemos simplesmente mesclá-lo com nosso commit principal. Em primeiro lugar, mudaremos para o branch master. Bom. Atualmente, estamos no branch Master e escrevemos git merge origin E pronto. Temos todas as alterações em nosso repositório local, bem como no repositório fog Isso é muito fácil e tudo se resume trabalhar em um projeto de código aberto. Não há ciência de foguetes para isso, temos que praticá-la duas a três vezes. 85. Ferramentas de colaboração no VS Code: Agora vamos ver algumas ferramentas de colaboração no código VS. Então, em nosso projeto, aqui podemos ver que estamos atualmente na ramificação master. Deixe-me mudar para o outro galho. Agora, deixe-me mostrar como podemos enviar mudanças para nosso controle remoto. Então, no arquivo Read Me, eu mudo esse título, digamos, começando com o VSCode Salve isso e agora vamos para o controle de origem. Escreva uma mensagem de confirmação, atualize, leia-me para VSCode e Agora, aqui podemos ver que temos a opção de sincronização de alterações. E se passarmos o mouse sobre isso, ele diz: push one commit to origins Design slash home branch Então, a partir daqui, também podemos empurrar. Além disso, se clicarmos nesses três pontos, também teremos a opção push Com isso, também temos opções de pull, clone checkout, fetch e muito mais interessantes Por exemplo, se usarmos CDs, aqui, podemos fazer o Commit normal, confirmar somente arquivos de estágio, confirmar, desfazer o último commit e também sobre o Temos mudanças, pull, push, branch, remote, stairs, tags e quase todas as opções que são frequentemente usadas no git Não quero te entediar mostrando todas as opções Já vimos essas opções usando a linha de comando. Então, aqui, eu faço um simples empurrão. E pronto. Nós publicamos as mudanças. Eu uso essas opções quando não quero abrir o terminal. Caso contrário, gosto de usar a linha de comando porque isso é mais claro para mim e também não gosto de usar o mouse quando estou codificando Eu não sei por quê. Se você quiser usar essas opções , tudo bem. Isso realmente depende da sua escolha pessoal. Não sou ninguém para dizer que você usa isso ou não usa aquilo. A escolha é sua. Também no painel de controle de origem, na parte inferior, podemos ver nossos cometas, galhos, controles remotos, estase, tags, árvore de trabalho e, na parte inferior, obtemos a lista de colaboradores desse repositório Além disso, a partir daqui, podemos adicionar um colaborador. Se você não quiser usar o site do Github. 86. Colaboração usando o Github Desktop: Agora vamos ver as opções de colaboração no aplicativo de desktop Github Então, aqui eu também altero o título do arquivo Leia-me para começar a usar o aplicativo de desktop Github Salve isso e deixe-me confirmar isso com uma mensagem, atualize, leia meu arquivo para o Github Dextop Bom. Agora, vamos para o aplicativo de desktop Github Atualmente, não tenho nosso projeto de repositório fog aberto no aplicativo de desktop Github, então preciso abri-lo Então eu vou para o arquivo, adiciono o repositório local, escolho caminho da minha pasta e adiciono o repositório Veja aqui que obtemos diretamente a opção push origin. Além disso, você pode abrir este projeto no Github usando este botão. Ferramenta muito útil. Agora, no topo, temos o repositório atual. Depois disso, temos a ramificação atual e, em seguida, podemos ver que pressionamos o botão de origem e, abaixo disso, obtemos detalhes sobre a busca No mundo real, quando estamos prontos para promover nossas mudanças, é uma boa prática primeiro extrair as mudanças da origem. Então, no lado direito, temos o botão. Veja aqui a origem do patch. Clique nisso. E se tivermos alterações, obteremos essas alterações em nosso repositório E se tivermos um conflito , antes de insistir, podemos resolver nossos conflitos E com isso, não precisamos pressionar novamente o Merge kat. Usando essa prática, podemos limpar nosso histórico de gatos. Agora, na parte superior, temos o menu do repositório e, dentro dele, temos muitas opções básicas para o git, como push, pull, fetch, remove e, na parte inferior, temos a configuração do temos Eu só gosto dessa opção porque aqui podemos alterar facilmente nosso repositório remoto Portanto, essas opções são muito semelhantes no código VS. O engraçado é que o código VS tem muito mais opções do que o aplicativo de desktop Github E é por isso que eu digo que desktop Github é um aplicativo simples, básico e amigável para iniciantes Vamos simplesmente ir até a origem e pronto. Agora, aqui podemos ver que podemos visualizar o pull request e também criar o pull request. E quando criamos uma nova pull request , podemos ver isso em nossa página de repositório Agora veremos outras opções na próxima lição usando o crack e o aplicativo Git 87. Colaboração usando o GitKraken: Agora vamos ver as ferramentas de colaboração usando o Git kraken. Primeiro de tudo, no Git Kraken, temos que abrir esse repositório fog porque atualmente Então vá para o arquivo, OpenRPO aqui, abertura e selecionamos nossa pasta de repositório e selecionamos Agora, aqui podemos ver que atualmente estamos na filial Design SLesome No lado esquerdo, podemos ver o nome da ramificação local, controles remotos, pull request atualmente ativo, que é zero Também podemos criar pull request a partir daqui. Depois disso, temos problemas, selecione aqui Github e obteremos os problemas Aqui, também podemos criar um novo problema e, depois disso, temos muito mais opções. Agora deixe-me te mostrar algo muito legal. Aqui temos repositórios. Depois disso, temos uma lista de ramificações que já vimos na seção anterior. Agora, depois disso, temos alguns botões que são muito úteis. Primeiro, vamos desfazer, que é para desfazer a última camada Se passarmos o mouse sobre esse botão, poderemos ver o que esse botão faz Então, desfazemos a última empregada. Veja, aqui está. Deixe-me refazer isso. Depois disso, temos o botão de puxar e, aqui, temos muitas opções. Pegue tudo, puxe se for possível avançar rapidamente, apenas avance e rebase Agora, depois disso, temos o botão de apertar e esse botão de ramificação para criar uma ramificação a partir desse commit selecionado atualmente. Agora, aqui, clicamos no nome desse ramo. Podemos ver que também recebemos pull request, push set upstream, que configuramos para enviar o branch pela primeira vez Também na parte inferior, podemos iniciar o pull request para essa ramificação e muito mais opções. Aqui, não temos muitas opções porque estamos trabalhando no repositório fog e não podemos enviar diretamente para o repositório base Vamos começar o pull request. Aqui, podemos selecionar nossa filial de nossa origem. Do nosso repositório fog, crie a ramificação Home e compare-a com a ramificação Master do nosso repositório base Agora escrevemos aqui, puxe o título da solicitação, então, atualizando, leia-me na página inicial de design. Aqui, também podemos escrever uma descrição e, a partir daqui, podemos simplesmente criar uma solicitação Pull. Também temos a opção de continuar editando no Github e veja aqui o site do Github. Basta clicar em Criar solicitação de pool. E pronto. Se tivermos um conflito, então aqui, podemos resolver esse conflito. E depois disso, a partir do repositório base, podemos mesclar essas alterações no repositório base Nós já vimos isso certo. Agora, da minha segunda conta, que é a autora desse repositório, vamos para a pull request Aqui, não temos nenhum conflito, então podemos mesclá-lo com branch E pronto. É assim que podemos trabalhar com ferramentas de corabação no Kraken Mas aqui está minha opinião pessoal. Se soubermos o que é push, pull, setup upstream, merge, rebase e todos os termos, usar a linha de comando git é muito mais fácil do que usar a interface gráfica do usuário Nas GUIs, podemos ver claramente a história. Mas para essas opções, eu pessoalmente acho que a linha de comando é uma opção muito melhor. Pode abrir nossa planilha de bate-papo a qualquer momento e escrever esse comando. Simples assim. Não precisamos encontrar opções ou não precisamos abrir o aplicativo desktop Git Kraken ou Github Em vez disso, podemos simplesmente usar Git Bash ou o terminal de código VS Então, isso é tudo sobre colaboração no git. Espero que você aprenda muito nesta seção. Depois desta lição, adicionei PDF de resumo e você pode adicioná-lo à sua planilha 88. Seção 06 Limpeza e organização do histórico: Bem-vindo à última seção do curso definitivo de TI. Nesta seção, veremos como podemos limpar e organizar as ajudas na marcha Então, veremos fazer confirmações, recompensar crianças, recuperar confirmações perdidas, descartar confirmações, alterar mensagens de comando, dividir, descartar confirmações, alterar mensagens de comando, dividir, esmagar e muito, Em palavras simples, reescreveremos ou enviaremos o git do histórico de commits. Então, vamos começar esta seção. 89. Reescrevendo o histórico de compromissos: Agora, a pergunta que você pode fazer é por que precisamos reescrever nossa história A razão pela qual escrevemos o histórico ou armazenamos o histórico do nosso projeto é que queremos ver como nosso aplicativo evolui com o tempo Pela história, podemos ver naquele ano quais são os recursos que lançamos, quais são os bugs que corrigimos, quem contribuiu para qual recurso e muitas outras coisas. Agora imagine que, no momento em que vemos nossa história, vemos uma mensagem de confirmação incorreta. Às vezes, cometemos pequenas mudanças, que podem ser feitas em confirmações únicas, ou fazemos grandes mudanças nas quais implementamos dois recursos juntos, o que não é bom implementamos dois recursos juntos, o que não é Às vezes, podemos querer excluir confirmações indesejadas e , nesse momento, precisamos reescrever nosso histórico de confirmações É por isso que esta seção é útil para tornar nosso histórico limpo e organizado, que é o sinal de um desenvolvedor profissional. Agora você pode perguntar: devemos reescrever histórico de commits de projetos remotos A resposta é não. Não devemos reescrever os commits que enviamos para o controle remoto, pois isso atrapalhará nosso projeto para outras pessoas e acabaremos com Em muitas empresas, somente a autoridade superior reescreverá a história Mas primeiro, ele ou ela traz uma reunião ou informa todos os membros da equipe sobre como reescrever a história Mas, como desenvolvedores, podemos reescrever o histórico de confirmações, que é local e não é enviado para o controle remoto Reescrevendo a história, podemos tornar nossa história mais limpa e organizada Na próxima lição, começaremos com o histórico de confirmações. 90. Desfazer o compromisso em detalhes (RESET): Então, primeiro de tudo, para esta seção, criei um projeto de TI chamado Course cartwis Você obterá o projeto na pasta de recursos que você baixou no início deste curso. Assim, você pode abrir essa pasta no Git Bash ou no terminal Vamos ver a história desse projeto. Veja, aqui temos uma lista de Commits. Aqui, queremos desfazer a amêndoa. Já vimos isso nas seções anteriores, mas eu só quero ter certeza de que não perderemos nenhum tópico. Então, como sabemos, para undo the amid, usamos o comando git reset, e esse reset tem três opções, LSD soft, LSDs mix, que é o padrão e o hard Deixe-me explicar cada opção, uma por uma. Então imagine que esse é nosso código de diretório de trabalho e queremos armazenar esse código em nosso histórico do Git Primeiro, organizamos nossas mudanças e depois fazemos o Commit. Agora, depois de algum tempo, trabalhamos corrigir um bug no design do layout. Novamente, organizamos as mudanças e as confirmamos. Agora, aqui queremos desfazer o Commit B e voltar ao commit A. Se escrevermos git reset the soft head até um, o desfará o commit no histórico do git Aqui, obtemos o commit A, mas ele não afetará nosso código de diretório de trabalho e código de área de teste Eles permanecerão os mesmos de antes. Você sabe que essa situação atual é qual condição? Quando fazemos alterações no diretório de trabalho e preparamos nossas alterações, mas não as confirmamos. Agora, suponha que no lugar está o software, escrevemos mixado, então ele desfará nosso último commit atual no cabeçalho até um, que é um commit no histórico Além disso, substituirá nosso código de área de teste pelo código Com A. Mesmo assim, ele não afetará o código do diretório de trabalho. Sabemos que essa condição é qual condição? Certo. Quando fazemos alterações no diretório de trabalho, mas não organizamos essas mudanças, você está realmente indo muito bem. Agora, se escrevermos dash hard , ele desfará toda a área do cabeçalho até que uma, que é uma que vem antes do head commit, que é A. Você conhece essa condição? Certo. Quando simplesmente fazemos o Commit A, todo o nosso código está no estado anterior. Vamos ver essas opções em ação. Digamos que queremos desfazer nossa última confirmação para a confirmação anterior Primeiro, vamos ver o que fizemos nesse commit. Obtenha a referência show Commit, que é a cabeça. Veja aqui neste commit que mudamos o estilo do arquivo CSS de pontos. E aqui adicionamos essas linhas de código. Então, primeiro, escrevemos git reset, da di soft. Aqui, escrevemos nosso Comitê tem ou ponteiro sobre o qual queremos nos mover Então ele, que é o Camttll atual, que é um commit antes desse Saiba que isso só desfará a confirmação no histórico de confirmações e não tocará em nosso diretório de trabalho e também não tocará na área de teste Portanto, nossa área de espera tem essas linhas, mas nossa permissão foi redefinida para a versão anterior Então, podemos ver isso vendo a diferença entre área de teste e confirmação Para isso, temos o comando Git df das cast Veja, aqui temos essas linhas. Agora, vamos escrever git reset, dd mixed, add till one comando desfará o comando atual na cabeça até um comando e também anulará as alterações Aqui, a partir desse comando, se removermos esse teste como misto, então, por padrão, usaremos o teste como misto. Podemos verificar isso vendo a diferença entre a área de trabalho e a área de espera Podemos usar o status do Git ou também podemos usar o GTF Veja, aqui temos essa diferença. Agora vamos ver a última opção, que é reinicializar, há essa cabeça dura até uma. Agora, todos nós, um código será redefinido para este cabeçalho até um. Agora, se virmos o DF ver, aqui não temos nenhuma diferença porque toda a área está voltada para um cometa Então, aqui nossos últimos três commits sumiram porque executamos o comando reset três vezes. É assim que podemos desfazer o commit de um commit específico. 91. Revertendo os compromissos: Na lição anterior, vemos como podemos desfazer o casaco. Agora vamos ver a reversão das amidas. Imagine que temos duas amidas em nossa história, que enviamos para o github Agora não podemos desfazer essas amidas e empurrá-las novamente. Ele corresponderá ao código de todos os membros da nossa equipe. Então, nessa situação, usamos revert, que significa que podemos desfazer as alterações feitas pela nossa omissão B e criar um Reverter significa voltar para a versão anterior, mas sem envolver as amidas anteriores Veja isso praticamente. Então, aqui temos nosso histórico de comprometimentos, e eu quero desfazer as mudanças feitas por esse terceiro cometa Imaginariamente, achamos que tudo isso é enviado para o controle remoto, então não podemos usar o git reset Então, usamos aqui o Git reword e aqui escrevemos a referência do Commit, cujas alterações de confirmação queremos desfazer, que é essa cabeça do Camt Se escrevermos cabeça até um , isso desfará as alterações feitas pela segunda Cate Aqui, também podemos reverter vários commits com um cometa. Se você quiser reverter todas as alterações feitas por essa faixa específica de cometas, podemos escrever algo assim Primeiro, escrevemos a referência do commit, um commit abaixo, que é ele até as quatro. Ponto duplo, aqui escrevemos o último commit, que é head. Lembre-se de que qualquer confirmação que escrevermos primeiro, ela levará as confirmações após esse período até a última confirmação Esse comando reverterá as alterações feitas por esses quatro commits e criará novos quatro Agora, o Git solicita uma mensagem de confirmação para cada nova recompensa amida Não quero alterar a mensagem de confirmação, então estou simplesmente fechando cada arquivo e pronto. Agora vamos conferir nosso histórico. Veja, aqui temos quatro Camts de recompensa. Agora, como podemos ver, reverter várias amidas está tornando nossa história Existe alguma outra solução que possa limpar essa bagunça? Sim, há uma pausa. Em vez de criar esses quatro cometas de recompensa individualmente, podemos reverter essas mudanças e colocá-las em um único encontro Então, primeiro, vamos remover esses quatro remédios. Nós não os queremos. Aqui, podemos usar reset porque essas quatro amidas não são colocadas no repositório remoto Então, usaremos reinicializações de portas com força e para onde queremos mover nossa cabeça Certo, queremos nos mudar para cá. Então ele, isso é cabeça até um, cabeça até dois, até três até quatro. Então vá até as quatro. Agora vamos conferir nosso histórico. Veja, aqui nós desfazemos esses quatro ametas. Agora vamos reverter novamente esses quatro cometas, mas criaremos apenas um Escrevemos Git, revert, dn, das amet e aqui escrevemos nossa referência Kameit Cabeça até a cabeça de quatro pontos duplos. Veja aqui que não obtemos nada, mas podemos ver que estamos no processo de reversão Atualmente, o git reverte todas as alterações que aconteceram nesses quatro comandos e coloca essas alterações na área de Podemos verificar isso usando git status S. S, aqui obtemos três arquivos com D, que é excluído e um com modificado e também tamp, que não é Revertemos as mudanças na área de espera. Se você quiser assistir às mudanças ou fazer mais algumas mudanças , podemos fazer aqui. Atualmente, não queremos fazer nada, então podemos escrever Get revert. Aqui temos duas opções. prestes a abortar a reversão, ou podemos continuar a reversão, o que nos levará a cometer essa reversão de uma só vez. Continuamos. Receba uma mensagem de solicitação de confirmação. Aqui temos apenas a última mensagem de confirmação de reversão. Podemos escrever aqui, reverter por último para Coit para degustação. Salve esse arquivo e feche-o. De volta ao terminal, veja a reversão concluída. E na história, também recebemos apenas uma reformulação em. Agora, como você pode ver, nossos três arquivos sumiram. Então, por enquanto, redefinimos isso novamente porque eu só quero mostrar a demonstração do revert, mas talvez precisemos desses Camtes no futuro Então, reinicie, há essa cabeça dura até uma e pronto. Agora, na próxima lição, veremos p log. 92. Reflog para recuperar compromissos perdidos: Agora imagine que em nosso código, nós redefinimos misticamente nosso código para ir até três Aqui podemos conferir a história do nosso cometa. Veja, perdemos nossos primeiros três mets. Agora, e se quisermos recuperar esses ametas? Agora, aqui você pode dizer que perdemos isso em. Como podemos recuperá-lo? No git, nós realmente não perdemos nada. Armazene-os no repositório e quando esses cometas perdidos ficarem longe por muito tempo, somente o Git os removerá Se redefinirmos nosso código bimstalmente, Git não removerá imediatamente Aqui, executamos o log Rf do Git, que é a forma completa do registro de referência Esse comando mostrará a referência do nosso ponteiro principal padrão Basicamente, ele nos mostrará como nosso ponteiro principal se move em nossa história Oh, o que acabamos de ver? Você sente tanta confusão? Só estou brincando. Isso é muito simples. Deixe-me explicar isso para você. Isso está apenas mostrando como nosso ponteiro principal se move. No início, obtemos o commit a, depois obtemos o identificador da unidade para esse ponto e, em seguida, obtemos a descrição dessa ação. No começo, eu fiz dez gametas em linha reta Com cada gameta, nossa cabeça se move. Depois disso, na primeira lição, executamos esse comando git reset três vezes. Em seguida, revertemos quatro vezes e depois reiniciamos, Camt e Agora, o bom disso é que temos todos os cometas aqui. E nesta lição, também reiniciamos por engano Lee. Então, só precisamos mover nosso ponteiro principal para essa referência anterior e recuperamos o cometa perdido Então, reinicie, não sei. Aqui, escrevemos nossa referência aproximada de registro ou podemos dizer esse ID de confirmação ou também podemos usar esse ID de confirmação. Cabeça em calibradores. Agora, se verificarmos nosso histórico de commits, veremos, obteremos nossos Cumms perdidos O que aprendemos com isso Quando executamos o comando git reset, o Git na verdade não remove esses Basta mover o Headpointer e colocar esses commits em algum lugar Se por muito tempo não tocarmos nesses comandos, somente o Git removerá esses comandos É assim que recuperamos nossos comandos perdidos usando f log. Agora, a única pergunta que muitos estudantes me fazem é podemos ver apenas o registro de referência do headpointer ou podemos ver qualquer registro de referência de ponteiros? Você está certo? Com o comando Git flog, podemos ver o registro de referência Você está certo? Com o comando Git flog, podemos ver Atualmente, não temos nenhuma filial. Vou te mostrar o log f desse ponteiro mestre. Git flog show, e aqui escrevemos o nome do nosso ponteiro, que Temos uma filial chamada carrinho de recursos, então escrevemos aqui um carrinho de recursos. Veja aqui que obtemos o registro de referência para o ponteiro mestre. É o mesmo que ponteiro principal porque eles se movem juntos nessa história Agora, atualmente, vemos todas as referências ou podemos ver o histórico completo. E se quisermos ver apenas os últimos cinco momentos do nosso ponteiro mestre Podemos simplesmente escrever aqui N espaço. Aqui escrevemos cinco. Veja, aqui temos apenas últimos cinco momentos do nosso ponteiro mestre Isso é muito útil, isso é tudo sobre ref log. Agora, na próxima lição, veremos como podemos fazer alterações nos quadrinhos existentes 93. Modificar o Commit recente: Agora vamos ver o comando emendar. Então emendar significa corrigir. Podemos fazer a correção em nosso comando recente sem criar um novo comando. Deixe-me te mostrar. Então, aqui no arquivo ML de pontos de índice, simplesmente alteramos o título para Cartwig Modern Ecommerce store Salve as alterações menos essas alterações e confirme essa alteração com a mensagem de confirmação, atualizando o título do aplicativo. Agora, aqui fizemos nosso Commit e, em nosso título, acho que precisamos colocar esse W em maiúscula na grafia Cardi e também adicionar um hífen entre E e commerce. Aqui, não queremos criar um novo Camt para essa pequena mudança Aqui podemos usar o comando amend. Fazemos alterações em nosso título, salvamos esse arquivo e vamos ensinar essas mudanças. Para Gamat, escrevemos a emenda Gate KamiTF apenas adicionamos a emenda Aqui escrevemos nossa nova mensagem de confirmação. Além disso, se você quiser usar a mesma mensagem de confirmação da mensagem de confirmação anterior , não escrevemos nada aqui. Veja, aqui temos a mensagem de confirmação anterior. Feche isso e pronto. Nós atualizamos nosso último kommt. Se quisermos verificar o que mudamos em nosso último Commit , podemos escrever Git show Veja, aqui temos um título atualizado. Agora, uma coisa que eu quero esclarecer é que não atualize realmente o último Commit. Cria oficialmente um novo comando porque os commits do Git são imutáveis, o que significa que, se criarmos um commit, Git não poderá Mas aqui mostra que está alterando o último commit. Agora, e se quisermos adicionar um arquivo no commit anterior? Para isso, temos que fazer o mesmo processo que acabamos de fazer. Aqui em nosso projeto, criamos um novo arquivo, raspamos dot js e, dentro dele, simplesmente consomamos o log de pontos do console Este é um arquivo de script. Salve esse arquivo e volte para o Git Pass, onde preparamos nossas alterações e simplesmente podemos usar o Git commit, dd Não vamos mudar a mensagem de confirmação. Agora, vamos verificar nosso último commit. Agora, ao adicionarmos um novo arquivo em nosso último commit, como podemos remover o arquivo? É um pouco complicado. Então, para isso, primeiro usamos o reset, e aqui usamos a opção mista de DDs porque queremos apenas redefinir nosso histórico de commits, e também redefinimos do estágio em que nosso diretório de trabalho permanecerá o mesmo de antes, área de ensino e o commit serão redefinidos Então, reinicie assim como o mixado, vá até um. C, removemos as alterações e, no arquivo STML de pontos de índice, obtemos nosso título Assim, podemos excluir esse arquivo temporário e agora podemos preparar nossas alterações E então, em vez de usar o Git commit, amend, usamos simple commit porque redefinimos nosso último commit e também enviamos uma mensagem, atualizando o título do aplicativo e criando o arquivo de script e pronto Então é assim que o comando amend funciona. Agora, e se quisermos alterar qualquer um desses compromissos, e veremos isso na próxima lição 94. Modifique qualquer commit no histórico: Então, na lição anterior, vemos como corrigir nosso último cometa Mas e se quisermos alterar alguma regra anterior? Digamos isso em estilos para o corpo do índice STML. Nesse meio, queremos mudar a cor de fundo do nosso corpo. Então, como podemos fazer isso? É muito simples. Primeiro, vamos verificar o que mudamos nesse casaco. Então, Git mostre d35, CB 01. Veja, aqui podemos ver que adicionamos estilo ao corpo, mas eu quero mudar essa cor de fundo. Aqui vamos usar o comando rebase. Deixe-me explicar para você o que o comando da base faz. Imagine que temos seis commits de A a F e queremos mudar o commit, digamos C. Temos que rebasear para o commit B porque a base do commit C é o commit B. Então, aqui fazemos alterações em nosso commit C e, como sabemos, os commits do Git O Git não pode alterar o commit. Git cria um novo commit que tem nossas alterações e depois o rebaseia com o commit B. Você pode perguntar: como o Git pode substituir o commit C pelo commit C E quanto aos commits D, E e F? A resposta é que o Git não substitua o commit C pelo C. Em vez de substituir o commit C, aqui, o Git cria o commit, mesmo que esse commit D, mas esse commit também tem a alteração que fazemos nos CDs Se o Git remover essa alteração no próximo commit , qual é o objetivo disso É por isso que o Git Pi é exatamente o mesmo commit do commit D, mas com alterações O mesmo vale para o commit E e o commit F. O Git remove essa ramificação anterior, e é assim que, usando o git rebase, podemos corrigir qualquer commit Mas certifique-se de alterar apenas os commits que não enviados, pois o rebase claramente reescreve Agora vamos ver o rebasing em ação. Então, aqui, qual compromisso queremos mudar. Escreva este. Então, copiamos o ID do commit de sua base, que é o commit anterior. Lembre-se sempre de que, para o rebase, precisamos usar a referência de confirmação anterior Agora, para rebase, escrevemos git rebase I para interativo. Basicamente, queremos contar ao Git. Queremos interagir ou fazer alterações em nossos compromissos. E aqui escrevemos nosso commit básico, que é 4239 Veja aqui em nosso editor de código, obtemos esse tipo de interface. Por enquanto, não usamos essa interface porque ela vai confundir você Veremos como usar essa interface nas próximas aulas. Aqui, de baixo, mudamos para a opção de texto Aqui temos esse tipo de linha. Não se preocupe. Esses são apenas scripts que o git executará, e todos esses são medicamentos do nosso pedido de confirmação antigo ao mais recente Aqui, no início de cada amet, temos a opção PC, que significa que o Git simplesmente escolhe esses cometas da história e os rebaseia Agora, e se quisermos mudar esse objetivo? Então, na parte inferior do arquivo, temos muitas opções e sua explicação. Então, para editar no local de pico, escrevemos a edição. Agora, não queremos editar outras amidas, mas se quisermos, também podemos escrever aqui, editar, salvar esse arquivo e incluir os dois Veja, aqui paramos neste Camt para edição, e atualmente estamos reformulando um dos cinco, e podemos ver que podemos alterar Então, agora podemos mudar o que queremos mudar neste casaco. Então, no estilo de arquivo CSS de pontos, eu quero mudar a cor de fundo para branco. E a cor tem 101010. Salve as alterações e vamos provar essas alterações. E também Gt ka mate, dash, dash, emendar. Desculpe, é um erro de digitação. Então, guarde o casaco, corra, corrija, emende. Continuamos com a mensagem omitida. Então feche isso. Agora, nesta fase, vamos ver a história. Veja, como eu disse, o Git inicia uma nova ramificação, e esta é nossa base em E aqui no topo, recebemos nossa emenda atualizada, Camt Agora, quando continuamos esse rebase, Git escolhe essas amidas e as coloca neste Camt e, em seguida, remove Agora, para continuar esse rebasing, escrevemos git rebase Ou, se quisermos , podemos escrever sobre. Por enquanto, vamos continuar esse rebase e não temos nenhuma outra Git conclui rapidamente esse processo Agora vamos conferir nosso histórico. Aqui podemos ver que nossa história é novamente linear. Se você observar, perceberá que todos os IDs de cometas são diferentes dos cometas anteriores Portanto, está confirmado que o Git cria novos cometas. Mas, como sabemos, isso é para organizar a história. Agora, se vemos em nosso código , também obtemos essas alterações em nosso arquivo CSS de pontos de estilo. As mudanças que alteramos são que o Camt também está disponível em todas essas É assim que alteramos qualquer Camd usando git rebase I. 95. Como soltar um Commit: Deixar cair um chapéu inteiro é útil quando cometemos nosso trabalho por engano Mas quando soltamos qualquer cometa, temos que ter em mente que estamos rejeitando todas as mudanças que fizemos naquele Em nossa história, temos esse trabalho em andamento, que eu fiz bimstalmente Vamos ver o que eu cometo com isso na marcha, mostre AC a 49c Aqui podemos ver no arquivo ML de pontos de índice. Em vez desse texto, adicionamos essa tag he e, em um arquivo CSS de estilo, adicionamos esse estilo para a seção. Agora, se derrubarmos esse comando , essas alterações desaparecerão. Então, para descartar também, usaremos o rebase. Em nosso exemplo anterior, temos seis confirmações, e se quisermos descartar essa confirmação C, usamos a porta rebase I, e aqui começamos com a base, que é a confirmação B. E, em seguida, eliminamos essa confirmação C. Aqui, novamente, criamos uma nova confirmação para as confirmações D, E e F e depois as substituímos pela confirmação B, isso é simples descartar Aqui, novamente, criamos uma nova confirmação para as confirmações D, E e F e depois as substituímos pela confirmação B, isso é simples Agora, e se neste commit C, criarmos um arquivo chamado página DML Em quaisquer três desses commits, alteramos algo nesse arquivo Então chegamos aqui em conflito porque, quando eliminamos o Commit C , nosso arquivo pg ML também será descartado. E em nossos outros commits, estamos fazendo alterações neste arquivo DML de ponto de página S. Então aqui temos o conflito. Não se preocupe, resolveremos isso da maneira que estiver usando a ferramenta Merge. Também é muito simples. Só estou dizendo que um conflito pode acontecer se abandonarmos nosso compromisso. Em nosso exemplo, aqui temos essas mudanças. Vamos abandonar esse commit e ver se há conflito ou não. O que você acha? Vamos ver. Então, primeiro, escrevemos git rebase I e aqui escrevemos nosso ID de confirmação anterior, que é nossa Novamente, aqui vamos para a mudança para texto e aqui temos esses scripts. Agora queremos colocar essa camada no local desse pico, escrevemos drop ou podemos remover toda essa arte do script, salvar as alterações, fechar esses arquivos e ver aqui o rebase com sucesso se verificarmos nosso histórico e ver que o progresso do trabalho , kate desapareceu porque não temos conflitos Deixe-me mostrar o que devemos fazer se tivermos um conflito porque isso pode confundir você e eu não quero que você se confunda Aqui em nosso projeto na pasta de componentes, criamos um novo arquivo chamado myders dot HTML Neste arquivo, basta adicionar aqui uma tag H, e esta é minha página de pedido. As mudanças e vamos essas mudanças. Além disso, crie minha página DML de pontos de pedido. Bom. Agora, novamente, mudamos algo nesse arquivo. Então, na tag ST, digamos que essa seja a lista de pedidos. Salve os genes, e vamos também organizar isso e confirmá-lo com a página Confirmar atualizações de mensagens para pedidos. Agora vamos ver nossa história. Digamos que queiramos descartar esse segundo commit. Então, fazemos git rebase I e confirmamos o ID da nossa base, que é 9981 Certifique-se de escrever seu ID de confirmação. Aqui, novamente, recebemos scripts em nosso editor de código. Queremos descartar esse commit, para que possamos removê-lo daqui. Salve esse arquivo e vamos também fechá-lo. No Git Bash, veja, aqui temos um conflito porque descartamos nosso commit e, nesse comando, estamos descartando todas as alterações, ou seja, criamos o arquivo HTML Moder Removemos meu ponto de pedido SDMLFle e, logo na próxima confirmação, faremos alterações no mesmo É por isso que temos conflitos. Na maioria das vezes, não enfrentamos essa situação. Mas se às vezes isso ocorrer , podemos fazer assim. Podemos verificar nosso status usando o status do Git como a, C, aqui temos D e U, o que significa exclusão e atualização. Então, para resolver isso, simplesmente escrevemos aqui a ferramenta git merge. Veja, aqui excluímos o conflito de mesclagem para a barra de componentes . O Moder dot sTML Local é excluído e remoto, que Nesses, temos modificações. Então, para modificado, podemos escrever A, para excluir, escrever D e para Abort, podemos escrever A. Aqui não queremos excluir nosso arquivo Optamos por Modificar porque queremos manter essa página do Moder em nosso Cmd Agora, se verificarmos novamente nosso status, aqui seremos adicionados e obteremos esse Moder dot sTML dot ORIG, que é o arquivo temporário que o Gate criou Podemos ignorar isso ou também podemos excluí-lo do nosso projeto. Agora vamos continuar nosso processo de rebase usando Continuar rebaseado Vamos continuar com a mesma mensagem e pronto. Agora, se verificarmos nosso histórico novamente, veremos nossas quedas em meio com sucesso. Então é assim que abandonamos nossa mente. Agora, na próxima lição, veremos como só podemos alterar a mensagem de confirmação. 96. Alterando a mensagem de compromisso: Agora, em nosso histórico atual, suponha que eu queira alterar a mensagem de confirmação dessa segunda confirmação porque a mensagem não está clara. O que você quer dizer com mudanças na estratégia de índice ML, que mudam. E esse tipo de mensagem de confirmação pode criar muita confusão. Portanto, é sempre melhor mudar essas mensagens, para que nossa história pareça significativa. Primeiro, deixe-me ver o que eu realmente fiz nesse commit. Eu realmente esqueci isso. Obtenha show D six, um 7d59 Ok, aqui eu adiciono esta seção de lista de produtos. Então, para alterar a mensagem de confirmação, também usamos aqui rebase Obtenha o rebase I e aqui escrevemos nosso ID de confirmação básico, que é 61a8 Lembre-se de que o commit básico está sempre à frente do Commit , que queremos rebasear Novamente, temos aqui o script. Agora, para alterar a mensagem de confirmação no local de pico, escrevemos uma recompensa. Aqui também podemos reformular vários comandos. Suponha que este último comando queiramos reformular. Escrevemos aqui, reformulamos. Agora, quando fecharmos esse arquivo, ele solicitará a mensagem de confirmação atualizada para quais comandos adicionamos reword Deixe-me mostrar para você, salve esses arquivos e feche esses arquivos. Veja, eu peço uma mensagem de confirmação para nosso primeiro comando. Aqui escrevemos adicionando seção da lista de produtos no arquivo DML de pontos de índice Salve e feche esse arquivo. E, novamente, podemos escrever uma mensagem de confirmação para nossa última confirmação , pela qual somos recompensados. Estou feliz com essa mensagem. Então, vamos em frente e pronto. Agora, se verificarmos nosso histórico, veja, aqui recebemos uma mensagem de confirmação atualizada. Agora, aqui, quero dizer novamente que, à medida que pagamos, crie novamente este Camt e, à medida que esse commit for recriado, todos os casacos serão recriados todos os casacos Portanto, está muito claro que estamos reescrevendo a história. Tudo bem se tivermos gametas em nosso repositório local, mas não devemos alterar os gametas que já foram enviados para 97. Alterar posições de commits: Agora, em nosso histórico, se quisermos mover os commits para cima e para baixo, digamos que aqui temos isso atualizando o título do aplicativo e criando o arquivo de script Commit Queremos mover esse commit para baixo nome dessa classe de anúncio no ponto de índice SDMLKit Então, aqui começamos novamente a rebasing get rebasi aqui escrevemos nome base do cometa onde queremos Suponha que aqui temos dez cometas, queremos mover os seis cometas após o terceiro encontro Nessa situação, começamos o processo de rebase a partir do cometa dois porque esse será a Agora, suponha que se quisermos colocar os seis cometas após os oito cometas, começaremos a nos basear a partir dos Para alterar a posição do repositório, sempre começamos a rebasear a partir do ponto É por isso que aqui começamos a nos basear a partir dessa posição. Nove E quatro, CD três D. Então nosso script de rebase tem tudo isso Agora, aqui, podemos simplesmente mover as linhas em qual ordem queremos reordenar o repositório Então, vamos para o título de atualização e o arquivo de script Cat e, simplesmente segurando Alt ou Option, seta para cima e para baixo, podemos alterar a posição das camadas no histórico, movê-las para o topo do histórico, salvar esse arquivo e cruzar esses arquivos Veja, aqui temos um rebase bem-sucedido. Vamos conferir nosso histórico. Veja isso em mover para baixo, então é assim que podemos mudar a posição de nossos ametas. Agora, na próxima lição, veremos como podemos mesclar dois ou mais ametas em um único ameta 98. Esmagar dois ou mais Commits: Agora vamos ver como podemos combinar dois ou três cometas. Então, aqui em nosso histórico, podemos ver a adição do nome da classe no arquivo SML de pontos de índice e a adição estilos para o corpo do índice dotLFle Esses dois códigos podem se combinar em um único cometa porque esse é o mesmo processo Então, vamos combiná-los. Aqui, iniciamos novamente o processo de rebase a partir daqui. Então, obtenha o rebase I seis F EA três F oito. Novamente, mudamos para o texto. Agora, queremos combinar esse segundo commit em nosso primeiro commit. Então, para o segundo commit no local de pico, escrevemos squash Se também quisermos combinar esse terceiro commit com esses dois , também podemos escrever aqui squash Por enquanto, não queremos isso, então voltamos a dar uma olhada Salve esse arquivo e feche-os. Agora, o Git solicitará a nova mensagem de confirmação. Aqui, recebemos todas as mensagens de confirmação, que eliminamos. Então, aqui, estou escolhendo essa primeira mensagem de confirmação e removo a segunda mensagem. Além disso, podemos alterar essa mensagem de confirmação para adicionar estilos ao ponto de índice sTML Salve esse arquivo e feche. Veja aqui nosso rebase concluído com sucesso. Vamos ver nossa história. Veja, só temos um cometa em nossa história de Comte. Agora, suponha que combinemos erroneamente esses casacos. E se quisermos desfazer o último rebase? Então, aqui usamos o log Gid Raf. Aqui podemos ver na parte superior, temos acabamento de rebase Depois disso, temos pico, pico, pico, squash e início de rebase Então, temos que mudar para este Camt onde terminaremos nosso rebase anterior Copie esse ID do Cait e vamos para a parte inferior E aqui escrevemos o Git, reinicializa com força essa Cam Vamos conferir nosso histórico. Veja aqui novamente, aqueles dois kamts separados Agora, a razão pela qual desfazemos essa abóbora é porque existe outra maneira de combinar nossas Escrevemos novamente, obtemos a base I, nosso amet base, aqui obtemos o script de rebase Agora, no lugar de escrever squash, podemos escrever Fix up. Agora você pode perguntar: qual é a diferença entre squash e fix up Então, eles são quase iguais. Mas, como sabemos, quando usamos squash, depois disso, temos a chance de escrever uma mensagem de confirmação para aquela confirmação combinada Mas quando usamos o Fix up , não temos a chance de escrever uma mensagem de confirmação. Escolha a primeira mensagem de confirmação como a mensagem de confirmação combinada. Aqui, nosso primeiro commit do repositório combinado é esse. Então, ele escolherá essa mensagem de confirmação. Salve isso e feche o arquivo. Veja, o kit conclui automaticamente o processo de rebase sem solicitar uma mensagem de confirmação, e nós colocamos essa mensagem em nosso histórico Agora, na próxima lição, veremos como podemos dividir uma única confirmação em duas ou mais confirmações 99. Dividindo compromissos: Agora vamos ver o último tópico de reescrever o histórico de commits, que consiste em dividir grandes ametas em pequenos cametas Aqui neste Camt, criamos uma página CAT e também uma página de perfil de usuário Isso pode ser um grande Kummet. Podemos dividir esse único Camt em dois cometas, um para a página CAT e outro para a página de perfil do usuário Aqui, nossa base Camt também está um cometa à frente deste. Deixe-me mostrar outra maneira de escrever em meio anterior. Aqui, selecionamos nosso commit atual e copiamos seu ID. Agora, escrevemos: git rebase, eu passo esse ID de confirmação atual e, esquecendo o commit anterior, usamos aqui Isso significa esse compromisso. Aqui, mudamos para o texto. Agora, essa amit que queremos dividir. Então, aqui escrevemos, editamos no local de pico. Então, quando fecharmos esse arquivo, ele permanecerá nesse commit e, usando o comando reset, podemos separar nossas ammts Deixe-me te mostrar de forma prática. Salve esse arquivo e feche-o. Veja, estamos em processo de reformulação. Vamos ver onde estamos exatamente em nossa história. Git log, veja, atualmente estamos neste Camt porque nossa cabeça está Agora, o que queremos fazer é usar o comando reset para remover nosso código de comitê atual da área de teste e também do nosso amet usar o comando reset para remover nosso código de comitê atual da área de teste e também do nosso Aqui, escrevemos git reset, soft, mas isso só removerá nosso código de at Deseja remover o código da nossa área de teste também. Para isso, escrevemos aqui, é misto. Agora estamos redefinindo o código de confirmação atual para qual código de confirmação Vamos voltar para o cometa anterior. Cabeça, sótão. Agora, em nosso diretório de trabalho, temos todas as mudanças que fizemos nesse grande meio, mas elas não estão em fase ou não estão prontas. Deixe-me esclarecer isso com o status do Git. Veja, aqui temos dois arquivos não rastreados. Então, aqui podemos fazer quantas confirmações quisermos. Primeiro, vamos nos comprometer com a página do carrinho. Então, preparamos o primeiro arquivo de página do carrinho, Git add components slash cart dot Nós nos comprometemos com a mudança. Git commit, implemente o recurso de carrinho Agora vamos conferir nosso histórico. Veja, aqui temos uma história diversa porque nossa base é essa e aqui nossos compatriotas anteriores Agora vamos criar outro commit para o perfil do usuário. Apresentamos aqui os componentes, cortam o ponto do perfil do usuário, o SGML e também o commitateGT, e também o commitateGT Agora, o motivo pelo qual não usamos aqui emend commit é porque não queremos mudar nosso commit atual Aqui, queremos criar um novo gato. Então git dM, implemente o recurso de perfil de usuário. Agora vamos conferir nosso histórico. Veja no topo, temos dois cometas separados Não se preocupe, ainda estamos no processo de rebase. Essa não é a saída final. Agora, quando continuarmos nosso processo de lançamento , o Git recriará esses outros cometas e os colocará no topo desses dois comentários. Dessa forma, obtemos uma história linear colocará no topo desses dois comentários. Dessa forma, obtemos uma história linear. O rebase do Git continua. Bom, fizemos o rebase com sucesso. Vamos verificar isso pelo histórico. Veja aqui que recebemos dois commits separados e nosso grande commit saiu de nossa história Para recapitular rapidamente, primeiro iniciamos o processo de rebase e, em seguida, usamos o comando no script de rebase Depois disso, quando estamos nesse grande commit, removemos nosso código atual da área de teste e da área de confirmação usando git reset, mixed head carat usando git reset, mixed head quilate principal significa que redefinimos nossa área de armazenamento e confirmamos o código com o código de confirmação anterior Aqui, podemos organizar as mudanças e confirmá-las, confirmar uma e também configurar novamente as alterações e, em seguida, confirmar, que pode ser a confirmação dois. E então podemos continuar o processo B e concluí-lo para que S divida o Commit e reescreva nosso histórico 100. Reescrevendo a história usando o GitKraken: Agora vamos ver como podemos reescrever nossa história usando o Git Aqui, eu duplico o projeto que ofereço para você praticar no início desta seção e simplesmente o abro no portão Kraken Aqui temos todos os remédios ruins e queremos reescrever a Agora, reescrever o histórico é muito fácil no gate cracker e também é o mesmo processo no código VS Agora, reescrever a história significa que temos que rebasear. Aqui, queremos iniciar o processo de rebase como base disso em Então, escrevemos, clique nesse commit e simplesmente selecione aqui o rebase interativo desse commit Em palavras simples, qual commit selecionamos, ele será definido como base kommt Agora, aqui simplesmente obtemos esse tipo de script de rebase. Já vimos essa interface no código Vas. Aqui, nessa lista suspensa, podemos alterar o comando. Veja, para o primeiro commit, eu seleciono reformular. Aqui podemos mudar nossa mensagem de confirmação. No local das alterações no ponto de índice SDML, escrevemos adicionar lista de produtos no arquivo SGML de pontos de índice e atualizamos a mensagem Agora também queremos mesclar esse terceiro comando com este segundo comando, podemos selecionar aqui squash e ver usando a seta, obtemos o squash claro Agora, aqui também queremos retirar esta capa de trabalho em andamento. Se obtivermos conflitos, pressione Kraken, solicite modificação, exclusão O mesmo que o Gitask em nosso Git Bash. Vamos começar o rebase, veja, aqui temos o conflito e podemos ver os arquivos conflitantes no lado direito Clique aqui e aqui pegamos as alterações de B e simplesmente fazemos C. C, o conflito acabou, e agora podemos continuar esse rebase ou também podemos abortá-lo. Vamos clicar em Continuar e ver se todas as alterações foram feitas. Essa é uma base simples em Git Kraken e viscode. Mas aqui está uma coisa. No Git Kraken ou no código Vs, podemos emendar, confirmar ou dividir cometas Para isso, temos que usar o terminal. É por isso que eu primeiro mostro o Git usando a linha de comando e depois para ferramentas de GI Agora, oficialmente, abordamos todos os tópicos da marcha. O que você acha? O que você mais gosta no Git Usando-o no terminal ou com ferramentas de interface do usuário. Gosto de usar a linha de comando para todos os comandos e ferramentas de GI para observar o histórico e rebase Sua escolha pode parecer diferente, mas é sua escolha pessoal. No final do dia, você precisa trabalhar no seu sistema. O que quer que usemos, nosso trabalho deve ser feito. 101. Seção 07 Comandos Git mais usados: Bem-vindo à seção de recapitulação do curso definitivo do Git. Nesta seção, veremos todos os comandos mais comuns na vida dos desenvolvedores. É como revisar os conceitos do git. Então, segure um pouco de água e aproveite esta seção. 102. Noções básicas do Git e comandos de histórico: Vamos começar com os comandos básicos do Git. Em primeiro lugar, para inicializar nosso projeto, usamos o comando Gain init Ou, se já tivermos um projeto na nuvem , usaremos o clone do Git e o URL Depois de receber nosso projeto, podemos fazer alterações em nosso código e, em seguida, podemos organizar essas alterações usando o Git add E aqui escrevemos o nome do nosso arquivo. Organizar as mudanças significa que essas mudanças estão prontas para serem aplicadas. É como uma área de espera. Agora, se você quiser organizar todas as mudanças , escrevemos aqui Git add period Então, se você quiser ver nosso status atual, escrevemos Git status ou git status para status abreviado Agora, depois de nos satisfazermos com nossas alterações, nos comprometemos com as alterações para armazenar esse código em nosso histórico de portões, para armazenar esse código em nosso histórico de portões usando o Git commit, e adicionamos aqui uma mensagem Aqui, certifique-se de escrever uma mensagem significativa. Se não adicionarmos nenhum arquivo novo, podemos usar esse comando de atalho, AM do Git commit Com esse comando, podemos configurar e confirmar nosso código em um único comando. Agora, se você quiser ver a diferença entre área de trabalho e o código de área de teste , podemos usar o Git DF. Se quisermos ver a diferença entre o código de área de teste e o código comprometido, Git dif, stage ou podemos usar o Git Di , stage ou podemos usar Depois disso, se quisermos ver nosso histórico de commits , podemos usar o comando Git log E se quisermos ver o histórico em uma linha , podemos usar o Git log, traçar uma Também podemos adicionar outras opções como um gráfico para o histórico do gráfico. Depois disso, se quisermos ver o que mudamos no Commit , podemos usar Git, show e commit ID Além disso, podemos usar o ponteiro principal dela e, se quisermos ver um arquivo específico , podemos usar o Git, mostrar, confirmar a referência e, com a coluna, escrever o caminho do arquivo Então, às vezes, queremos mudar o código de um commit para outro. Em seguida, podemos usar o checkout do Git, o ID do commit ou também podemos usar o Git, switch, Agora, se em nosso projeto alguém escrever um código muito ruim e verificar o autor de cada linha, podemos usar o Git, blame e aqui escrevemos o caminho do arquivo, que queremos culpar Se quisermos ver linhas específicas, podemos adicionar aqui a opção L, e aqui escrevemos a linha inicial, vírgula, número da linha final Depois disso, outro comando mais usado para marcar commits do Git é git tag, nome da tag Em seguida, escrevemos nosso ID de confirmação para o qual queremos criar essa tag. Se quisermos remover a tag , usamos a tag Git, D, e aqui escrevemos o nome da tag e, para C, a lista de tags, simplesmente usamos o comando Git tag Esses são os comandos importantes relacionados aos conceitos básicos do Git e para observar o histórico de commits 103. Comandos de ramificação e mesclagem: Agora, vamos recapitular sobre filiais. Quando quiser trabalhar em recurso separado ou simplesmente trabalhar em sua equipe, crie uma nova ramificação e trabalhe nessa ramificação. Se quisermos ver a lista de todas as ramificações , temos o comando git branch E para criar uma nova ramificação, usamos a ramificação e o nome da ramificação do Git Depois de criar uma nova ramificação, precisamos mudar para essa ramificação, e podemos fazer isso usando o nome da ramificação Git switch Agora, se quisermos criar uma nova ramificação e também quisermos alternar em um único comando , escrevemos Git switch, C e nome da ramificação Agora, para ver qual é a diferença entre uma ramificação específica e nossa ramificação atual , podemos escrever o nome da ramificação Git Div Além disso, podemos ver a diferença entre duas ramificações usando Git, D ramificação um, ponto ponto ramificação dois Agora, se estivermos trabalhando na ramificação um e, de repente, tivermos que trabalhar na ramificação dois, em vez de confirmar metade do código, podemos armazenar esse código Escadas são como manter esse código em um canto, depois podemos mudar para outra ramificação e completar a nossa ou depois disso, podemos aplicar as escadas em nossa ramificação anterior. Para criar as escadas, usamos escadas do Git, empurrar e aqui adicionamos a mensagem Ss para ver todas as escadas, usamos a lista de estatísticas do Git Agora, se quisermos aplicar as alterações das escadas em nosso diretório de trabalho , podemos usar o Git, apply e stats ID Depois de aplicar as alterações dessa escada, podemos descer essa escada usando git stash, drop e stats ID E se quisermos remover todas as estadias do projeto , podemos usar o Git clear Agora, depois disso, se terminarmos com nossa ramificação, poderemos mesclá-la com nossa ramificação principal E para isso, podemos mudar para a ramificação principal e, em seguida, mesclá-la usando git merge Se tivermos um histórico de divergências , o Git fará uma mesclagem de três vias e, se tivermos um histórico linear , o Git passará Depois de mesclar nossa ramificação na ramificação principal, podemos descartar essa ramificação usando Git branch, D, nome da ramificação Se quisermos eliminar essa ramificação à força, podemos usar Git branch , D, Além disso, podemos redefinir o Kamed para a versão mais antiga usando git No reset, temos três variações. Git reset, dash dash soft, Kate, que redefine o código do coat, git reset, dads mixed, que redefine o código do a e do Camt Se usarmos o Git reset ds hard, todo o nosso código de área será redefinido com esse código de comitê Agora também podemos reverter o mid e a diferença entre reset e amid é com revert, Git cria um novo met, mas no reset, o Git não cria Fará mudanças no Camt atual. Para reverter, usamos Git revert e, se quisermos reverter para o cometa pai, que é o cometa anterior de nossa ramificação atual, escrevemos aqui um e depois escrevemos Comte, que queremos reverter, que Por fim, se você quiser copiar um código do Comite em nosso Camt atual sem mesclar, podemos usar a referência de confirmação do Git cherry peak Esta é a visão geral da ramificação e mesclagem. 104. Trabalhando em comandos de equipe: Agora vamos recapitular sobre o trabalho em equipe. Em primeiro lugar, quando estamos trabalhando em equipe, maioria dos comandos que usamos é git fetch, que é usado para buscar alterações de todas as ramificações do nosso Depois disso, se quisermos buscar especificamente as alterações de apenas uma ramificação , podemos escrever git Aqui escrevemos nossa origem de nome remoto, que é o nome remoto e de ramificação mais usado. Se quisermos buscar do master , podemos escrever git fetch origin master ou podemos escrever somente git fetch. Isso funcionará da mesma forma. Agora, como sabemos, usando o comando fetch, obteremos apenas alterações em nosso histórico Nosso diretório de trabalho permanece o mesmo de antes. Se quisermos aplicar essas alterações diretamente de forma remota , no lugar do git fetch, usamos o git Mas lembre-se de que isso criará um novo commit. Agora, se concluirmos nossas alterações e quisermos empurrá-las para a nuvem. Temos que escrever git push origin, master ou main, seja qual for o nosso projeto Além disso, podemos usar aqui o comando de atalho, que é o Git push Agora também podemos enviar nossa tag para o controle remoto usando git push, origin e nome da tag para remover a tag da origem Usamos git push origin, dash delete, dash delete, Agora, se criarmos uma nova ramificação e quisermos empurrar essa ramificação para a origem , primeiro precisamos criar uma ramificação upstream Escrevemos o nome do branch de origem do git push. Depois disso, se quisermos novamente fazer alterações nessa ramificação , podemos usar um simples empurrão de porta. Git enviará as mudanças para essa ramificação, isso é tudo sobre trabalhar em equipe 105. Muito obrigado: Então, parabéns. Você acabou concluir o curso definitivo de Git e Github. E eu só quero te perguntar, você aprendeu o git Consegui explicar conceitos que ajudarão você a entender o Git? Eu realmente espero que sim. E neste vídeo, eu só quero dizer, muito obrigado por assistir este curso completo de TI e Github Sou muito, muito grata por isso. E, por favor, se você quiser compartilhar sua avaliação sobre este curso , na parte superior, você pode ver o botão de bater e, com isso, você pode compartilhar sua avaliação O que quer que você queira dizer, positivo ou negativo, é muito importante para mim. Dar esse feedback não levará mais do que 10 segundos, mas isso me dará inspiração e motivação para criar mais cursos melhores, além de me ajudar a alcançar mais estudantes que desejam aprender Git e Github como você Muito obrigado por assistir este curso e por tudo de bom em sua jornada de desenvolvedor, e espero que todos os seus sonhos se tornem realidade.