Git e Github básico para designers, estudantes visuais e qualquer pessoa.

1. O que é o controle de versões: Então vamos falar um pouco sobre o Git. O que é o Git? Git é controle de versão e o que é controle de versão? O controle de versão é essencialmente um controle de histórico. É como um desfazer. Ele permite que você volte para o seu projeto se você fez algo que gostaria de não ter feito e quer voltar a ser como era antes. controle de versão permite que você faça isso. É uma máquina do tempo a esse respeito. Se você nunca viu o clássico filme dos anos 80 de volta para o futuro, esta é a máquina do tempo que eles têm e aquele filme. Vou fazer referência a ele talvez uma ou duas vezes então se você não viu, você tem que ir assistir. O que o Git vai fazer é deixar você voltar no tempo. Ele vai armazenar instantâneos de seu projeto em um determinado momento e, em seguida, como você passar por seu projeto e você cometer mais e mais snapshots, você tem esses diferentes pontos no tempo como você pode voltar para, caso decidir que você quer desfazer alguma coisa. Isso não é tudo, que o controle de versão faz. O que o controle de versão é realmente ótimo é gerenciar a maneira como vários colaboradores interagem em um projeto. Então aqui temos três contribuidores. Eles estão todos empurrando contribuições para uma base de código central ou qualquer projeto realmente ou é chamado de repositório e esta é a versão perfeita ou pelo menos a mais recente do seu projeto. Uma coisa que você pode ver sobre este modelo aqui é que ele é muito da esquerda para a direita. É unidirecional e esses colaboradores realmente não têm uma ótima maneira de interagir uns com os outros e compartilhar código e coisas assim. Como um colaborador, se você quiser experimentar um pouco com o seu projeto, você terá que fazer uma cópia completa dele e brincar com ele e depois voltar e empurrar suas contribuições para a versão perfeita. Git como uma resposta para isso, estabelece essa idéia de controle de versão distribuída e o que isso é, é uma maneira de separar esse fluxo linear e introduzir algo que é um pouco mais colaborativo. Então aqui você tem três contribuidores e não só eles são capazes de enviar seu código para o repositório, mas eles também podem compartilhá-lo entre si. Eles podem compartilhar uns com os outros, eles podem empurrar até o repo, eles podem até mesmo puxar do repo, eles podem puxar um do outro, mas como você pode ver, isso pode ficar muito confuso. As coisas estão indo por todo o lado e sem alguma maneira de gerenciar isso, você pode entrar em um monte de problemas em um projeto. É aí que entra esse fluxo de trabalho, e é aí que vamos chegar sobre esse assunto e lições. 2. Obtenha a git e em em corredor: O que vou te mostrar agora é como entrar na sua máquina. Provavelmente a maneira mais fácil de fazer isso é se você acessar Mac.GitHub.com. GitHub é projetado para realmente grande cliente para usar com git. Vou passar por uma maneira mais simples de usá-lo, porque há muita coisa acontecendo aqui e se você não entende exatamente o que está fazendo, pode ficar muito louco. Vou guiá-lo passo a passo no terminal, que é a janela para o funcionamento interno do seu computador. Se você já viu algum filme de hackers dos anos 80, isso é o que eles usaram para invadir o mainframe. Mas a maneira mais fácil de instalar é baixar o cliente GitHub do Mac. Não se preocupe em abrir o aplicativo, sinta-se à vontade para entrar lá e bisbilhotar. Se você não tem nenhuma configuração de repositórios Git já, você realmente não verá nada interessante acontecendo, mas ele empacota todo o software Git com ele, então vá em frente e instale isso. Se você não quiser baixar isso, você pode simplesmente ir para o site oficial do Git, git.scm.com e baixá-lo lá, bem como , siga as instruções, é muito fácil fazê-lo funcionar. Uma vez que você tem que baixá-lo, você pode abrir o terminal. Você pode comandar espaço para puxar o Finder rápido lá, ou você pode ir através de seus aplicativos para baixo do terminal, ver o terminal de utilitários bem ali e abri-lo. Por padrão, ele irá soltá-lo em sua pasta de usuário. Eu crio um diretório chamado espaço de trabalho, para manter muitos dos meus projetos ativos. Vamos lá agora, está limpo para esta demonstração, mas normalmente haveria um monte de projetos aqui. Então vamos criar um novo diretório e vamos chamá-lo de primeiro repo, lá vamos nós e eu vou colocar algo lá dentro. Vamos abrir a edição de texto, e colocaremos um “olá mundo”, guarde isso. Hello.txt, lá vamos nós, e tudo o que está realmente fazendo é colocar algo neste diretório para que possamos fazer um repositório Git para ele. A maneira mais fácil de fazer um repositório Git é digitar Git init, e isso é abreviação para inicializado. A primeira coisa que vou querer fazer é entrar no diretório que criei. Se você nunca usou o terminal antes, há muitos comandos que permitem criar diretórios, excluir diretórios, criar arquivos, excluir arquivos, saltar pela estrutura de diretórios. Vou dar-lhe alguns dos conceitos básicos no curso desta lição, e estas são coisas que são realmente úteis. O primeiro sobre o qual vou falar é CD, que mudou o diretório. Então eu estou indo para CD no espaço de trabalho, e o que eu acabei de fazer lá foi basicamente dito do meu usuário. Então, se eu voltar para o usuário aqui, usuário, onde você está? Veja, este é Tilde, aquele é o rabiscado lá. Tilde é sua pasta pessoal, testy é o nome de usuário para minha conta de teste aqui que eu estou trabalhando para esta demonstração, e lá estou eu pequena casa e lá está meu espaço de trabalho e eu criei o primeiro repo. Então, quando eu disse espaço de trabalho do CD, eu estava em tilde, que é meu diretório home aqui, e eu disse mudar diretório para espaço de trabalho e lá estou eu, e agora eu estou indo para CD no primeiro repo. CD, primeiro repo, sem espaço. Uma vez que eu estiver lá, eu posso digitar ls, que significa lista e eu posso ver meu arquivo Olá que eu criei, e agora eu tenho um lugar para começar meu Git Repo. A primeira coisa que vou fazer é dizer git init. Sempre que eu estou digitando comandos que o Git deve reconhecer, eu vou prefá-los com a palavra-chave Git lá. Eu vou estar fazendo coisas como git add, git clone, git commit, a maioria das coisas que só funcionam no programa Git. Git init é o primeiro que você vai usar. Ele inicializou o repositório Git vazio, então com esse comando, estamos rastreando um arquivo. Agora, se eu fizer alterações nesse arquivo, ele será rastreado pelo Git e esse é o começo da sua experiência no Git. 3. Organizando e e fazendo sua: Vamos percorrer algumas das etapas básicas que você vai usar enquanto você está pedindo ao GIT para ajudá-lo a salvar as alterações em seu projeto. Nós conversamos sobre essa idéia de tirar instantâneos no tempo de seus projetos, caso você queira voltar para eles. Toda vez que você tira um desses instantâneos, você está confirmando suas alterações nesse repositório do GitHub. Então vamos dar uma olhada no que acontece. Existem algumas etapas que acontecem neste processo de licitação. Então, primeiro você digita seu código, você está criando novo conteúdo, seja lá o que for que você está fazendo. Você obtém vários arquivos juntos, digamos que você decide que está pronto para cometer. Você chegou a um lugar onde seu projeto está funcionando, ou você está em um estágio onde você está pronto para desenhar uma linha na areia como se fosse e tirar uma foto no tempo. Você chegou à parte de preparação do seu projeto, que você vai fazer é dizer, hey GIT, eu tenho esses arquivos específicos que eu gostaria de me preparar para cometer. Você pode não querer confirmar todos os seus arquivos. Assim, o processo de preparação permite que você adicione seletivamente o que você gostaria de confirmar. Então você vai passar para realmente cometê-lo. Eu gosto nestes dois estágios de preparar algo para o transporte onde você está embalando em uma caixa, e quando você coloca seu teto para cima e você está dizendo, “Lembre-se de todas essas coisas, tire uma foto deste ponto em tempo.” Então, toda vez que você está passando e fazendo um desses compromissos, você está empacotando um ponto no tempo e tendo o GIT para se lembrar disso para você. Então, agora falamos um pouco sobre esse processo de adição, preparação e confirmação, vamos dar uma olhada no que isso parece enquanto você está no terminal trabalhando com o GIT. Atualizei o arquivo Helloworld. Então vamos fazer um status do Git e ver o que o Git tem a dizer sobre nosso projeto aqui. Então você vê essas duas entradas vermelhas são hello.rtf arquivo, que você esperaria ser modificado desde que temos trabalhado nele, e então este outro arquivo não rastreado, .ds store, que é um arquivo de sistema que a Apple usa para rastrear a maneira como você tem configuração de sua pasta e quando você olha para ela na janela do Finder, qualquer maneira, ele não é o arquivo que você normalmente enviaria para um repositório. Não há necessidade de passar isso para outros desenvolvedores. É aqui que esse processo de adição vem a calhar. Ele vai permitir que você adicione seletivamente coisas ao seu repositório em vez de apenas o que está na pasta porque pode haver este é um arquivo que você normalmente não veria, ele vai ponto antes dele, há outros invisíveis arquivos que você normalmente não vê que podem ser confirmados sem que você saiba. Então vamos apenas fazer um git add hello.rtf, fazer um status git, ver o que acontece. Então aqui vamos nós. Você pode ver que hello.rtf está em verde agora e ds armazena ainda em vermelho, ele está listado como um arquivo não rastreado. Então isso é bom. Não queremos rastrear essa. O que queremos rastrear foi adicionado em encenado para ser comprometido. Então, agora, vamos em frente e confirmar esse arquivo. Quando você submete um arquivo, precisamos deixar alguma mensagem, você precisa dizer o que você fez, que código você está adicionando, quero dizer, não necessariamente código, em nosso exemplo, pode ser uma receita, precisamos deixar alguma mensagem, você precisa dizer o que você fez, que código você está adicionando, quero dizer, não necessariamente código, em nosso exemplo, pode ser uma receita, podem até ser arquivos do Photoshop. Você pode obter praticamente qualquer coisa para o seu repositório, que você deixa uma mensagem, então traço m é abreviação para mensagem. A mensagem tem que estar entre aspas, atualizado Olá Message.Então eu vou apertar Return. Recebo um monte de coisas de volta do Git. Você realmente não tem que prestar muita atenção a isso, desde que não haja um erro, então tudo bem, então agora eu posso fazer o status Git. Tudo o que vejo é pelo arquivo da loja de DS, está no caminho certo. Então isso é pouco passo por lá, eu trabalhei nele, eu adicionei, e então eu comprometi, eu tenho este arquivo está preso o arquivo em uma caixa dizendo, hey, isso é o que eu pretendo cometer. Isto é o que eu pretendo deixar para trás e então eu embrulho essa caixa e deixei uma mensagem nela, e é tirada como um instantâneo, é um ponto no tempo que o Git vai lembrar para mim. Há outra coisa para a qual quero chamar a sua atenção. Se você for fazer um commit, digamos que adicionamos algo mais aqui, passamos pelo nosso processo novamente. Lá vamos nós. Eu faço Git commit, se eu esquecer de digitar o traço m abreviado, Git ainda vai querer uma mensagem para mim e aqui está o que vai acontecer. Eu vou entrar em uma coisa chamada VIM e este é um dos editores de texto mais antigos lá fora, ele vai muito atrás, e pode ser um pouco estranho de usar. Então você começa com esta mensagem, ela diz por favor digite a mensagem de confirmação para suas alterações. Você pode ler isso muito bem. O que você faria é, algo como isso você diz datado [inaudível] Você vai notar que eu sou um modo de inserção. Esta é a palavra inserida na parte inferior. Isso vai deixar você digitar. Quando você desliga isso, você está apenas em um modo de leitura. Para sair, digita um cólon. Oops não lá, entretanto. Você aperta a tecla de escape para sair do modo de inserção. Lá vamos nós. Digite dois pontos e escreva w para gravação e q para sair. Talvez queiras escrever isso porque se alguma vez te envolveres neste mundo VIMWorld, não funciona. Se você não gastou o tempo, pode ser difícil voltar, e pode ser frustrante. Então anote cólon WQ. Lembre-se que, vamos pressionar enter, eu sou levado de volta para a minha janela do terminal, e eu recebo a mesma mensagem que eu estou acostumado a ver quando eu faço um git commit traço m. Eu só quero que você saiba que no caso de você acidentalmente entrar naquele universo VIM, queremos escapar do cólon WQ, retornar. Isso vai te tirar daqui. 4. Como criar futuros alternativos no Git: Até agora, falamos sobre o que é o controle de versão, o que é o Git, como instalá-lo, como preparar e submeter arquivos. Vamos seguir em frente e conversar com algumas das principais características do Git, o conceito de cabeça, e então a prática de ramificação e fusão. Isso nos dá a chance de usar nossas excelentes metáforas de viagem no tempo “De Volta para o Futuro” também. Então aqui vamos nós. Você está familiarizado com isso. Estamos indo junto, estamos fazendo instantâneos em pontos-chave do nosso projeto para que possamos preservar esses estados. Se olharmos para esta linha do tempo, chama-se mestre. É a linha de tempo padrão que você obtém quando você inicializa um repositório Git. Você pode ver aqui se eu faço um status Git no branch master. Então, à medida que avançamos e fazemos essas mudanças e as comprometemos, estamos protegidos contra um adesivo real pela capacidade do Git de nos deixar voltar a um ponto anterior no tempo em nosso projeto e começar de novo. Agora você vê o pequeno triângulo que eu apareci. É onde estamos nesta linha do tempo. Esse é o conceito de cabeça no Git, é a sua máquina do tempo, é onde você está agora no seu projeto. À medida que você avança, você faz mudanças. A cabeça é onde você está agora. Então vamos falar sobre ramificação. É aqui que entramos em nossas metáforas de Volta para o Futuro. Voltar para o Futuro centra-se em torno de Marty McFly, um adolescente em 1985. Os pais dele são chatos e as coisas não estão indo muito bem. Ele quer pegar o carro emprestado para sair com a namorada, mas o chefe do pai pegou emprestado e destruiu. Então, no filme, o que acontece é que Marty volta no tempo para 1955 porque tudo isso poderia ter sido evitado se seu pai tivesse apenas convidado sua mãe para o encantamento debaixo do mar dança e eles tivessem se apaixonado. Ele viaja de volta a 1955 e estabelece um conjunto de circunstâncias em que eles se encontram na dança sob o mar e tiveram seu primeiro beijo e se apaixonaram. Ele cria um futuro alternativo e quando ele voltar para 1985, tudo é incrível. Então, em nossos projetos, fazemos coisas assim. Começamos uma nova filial e nesta filial está o nosso futuro alternativo. Trabalhamos em nosso projeto, tudo corre bem e quando estamos em um ponto em que queremos fundi-lo de volta ao ramo mestre, que é o nosso ramo perfeito, fazemos isso usando uma fusão. Então, agora em Regresso ao Futuro, voltamos a 1985, tudo está indo bem. George é um escritor de sucesso, Loraine ainda ama George, e Marty tem um caminhão incrível agora. Esse padrão de ramificação e mesclagem é o núcleo do bom fluxo de trabalho do Git. Ele permite que você tenha a liberdade de experimentar, para experimentar esses novos recursos sem mesclar sua linha de tempo mestre. Você pode ver esse padrão onde você sobe, você tenta algo novo, ele funciona, você coloca de volta, você sobe, você adiciona o próximo recurso, ele funciona, você coloca de volta. Isso é praticamente o núcleo do bom fluxo de trabalho do Git. 5. Viagem no tempo de terminal em em que a medida em movimento em em sobre a venda e a marcação e a fusão: Aqui estamos nós. Vamos dar uma olhada prática no que acabamos de aprender. Vamos olhar para mover a cabeça ao redor, para fazer ramificação, e fazer fusão. A primeira coisa que vou fazer é, vamos ver aqui. Faça um git init e configure este repositório git. Comecei com um novo para este exemplo e vou fazer um arquivo hello.txt. Eu digo toque hello.txt e você pode ver aqui na janela do Finder que eu tenho que git repo e hello.txt. Agora você pode não ver isso.git e isso.DS_Store. Eu escolhi mostrar arquivos ocultos, existem arquivos do sistema que normalmente você não verá como um usuário. Se você Google isso, há um realmente fácil se você pode copiar colar esse comando em sua janela de terminal e ele mostrará esses arquivos para você. Eu gosto de tê-lo ligado. A primeira coisa que vou fazer é configurar um ficheiro.gitignore. Lá vamos nós. Agora, eu posso abrir os dois em Sublime Text. Lá vamos nós. Sublime Text é um grande editor de texto, eles têm muitos plugins para ele. Também é gratuito para um download de teste e eu recomendo usá-lo se você quiser apenas experimentar algo. Comece com gitignore. A primeira coisa que eu coloquei em um arquivo gitignore e o que este arquivo faz é ele diz ao git para não rastrear os arquivos que você listar explicitamente aqui. Normalmente eu adiciono gitignore dois o arquivo gitignore. Em seguida, em segundo lugar, este é um arquivo de sistema que Macs usou para rastrear alterações na pasta e é uma explicação suficiente para dizer que você não precisa rastreá-lo em seu repositório do GitHub. Eu tenho essas duas coisas lá e agora eu vou começar com o meu hello.txt. O que eu vou ilustrar é uma série de commits e, em seguida, como você pode se mover naqueles. Digamos que eu tenha uma ótima idéia para um poema e vou salvar isso. Gosto muito destas duas linhas. Vamos fazer um pequeno diagrama aqui em baixo. Vamos dizer que este é o nosso primeiro compromisso. Basicamente, vou começar a construir uma pequena linha do tempo só para ilustrar onde estamos nesta coisa. Eu vou salvá-lo, ir para aqui, fazer status git, e ele diz que eu estou no ramo mestre. É o meu primeiro commit e é um hello.txt é o arquivo não rastreado. Vamos fazer git add hello.txt. Agora podemos cometer, git commit - m para mensagem. Vou dizer, adicionando as duas primeiras linhas do meu novo poema. Lá vamos nós, então eu o comprometi. Agora eu posso verificar isso e ver git tem um comando chamado log. Se você fizer o log do git, você verá o commit que você acabou de fazer. Ele tem esse número de commit longo louco que é exclusivo para aquele commit e diz quem fez isso, quando eles fizeram isso, e então dá a mensagem de commit. Isso é ótimo quando você está trabalhando em um grupo porque você pode acompanhar todos os diferentes commits e dar uma olhada no histórico. Vamos fazer um pouco mais sobre o poema aqui. “ Mundo tão alto.” Sim, isso está se sentindo bem, estou gostando desse poema. Vamos nos comprometer novamente, vamos fazer um segundo commit. Vou chamar este de B e vou fazer uma pequena flecha para mostrar onde estamos aqui. Adicione este, faça o status do git. Modificado hello.txt, então vamos fazer git add hello.txt, git commit -m para mensagem, adicionando a terceira linha e, em seguida, confirmamos isso. Vamos registrá-lo novamente e ver o que temos. Aqui está o nosso primeiro compromisso, adicionando as duas primeiras linhas do meu novo poema. Então aqui você vê o que acabamos de fazer, então ele os lista do mais recente para baixo. Tudo, ok. Até agora, bem, vamos continuar. Temos outra linha do poema. Eu vou cometer este aqui, ele vai passar pelo status git usual, git add, git commit. Vamos registrá-lo e ver o que temos aqui. Temos todos os três. Isso tudo deve estar fazendo sentido e realmente provavelmente ficando um pouco chato escrever agora. Digamos, no entanto, que estou tendo dúvidas sobre esta última linha. Talvez eu gostaria de mudá-lo, mas eu já o cometi. Não, o que posso fazer para ultrapassar este compromisso? Bem, eu posso ir redefinir e então aqui está um termo que você vai reconhecer HEAD. Eu poderia pegar o HEAD e redefini-lo para um ponto diferente nesta linha do tempo. Eu mostro isso dizendo [inaudível] que é um pouco rabiscado no canto superior esquerdo ao lado do cais ESC no Mac, em qualquer lugar. Isso diz, pegue a cabeça e volte um, volte para o último commit. Lá vou eu, agora minhas mudanças estão no palco depois dessa reinicialização, e você pode ver que nada realmente mudou aqui. Mas se olharmos para o log do git, você verá que eu tenho o que diz adicionar as duas primeiras linhas e adicionar a terceira linha. Mas esse compromisso se foi. Então nós desfizemos esse commit. Voltámos no tempo na nossa pequena máquina do tempo chamada cabeça. Agora vamos dizer que eu não quero manter essa última linha em tudo. Vamos fazer isto. Vamos mudar isso para algo que faça um pouco mais de sentido. Lá vamos nós. Eu guardo isso. Então eu git add e eu git commit e eu git log e você pode vê-lo. A quarta linha, lá vamos nós. Digamos que também não estou feliz com isso. Se eu quiser estragar toda esta última linha, todo este compromisso C que eu fiz. Não estou preocupado em manter nenhum arquivo. Eu posso fazer um git reset - -hard, e depois dar-lhe um índice para a cabeça, HEAD~1. O que isso vai fazer é explodir tudo neste commit e mover a cabeça de volta para o último commit. Então, uma vez que eu pressione Return aqui, você vai ver a mudança de texto ao longo do bloco de texto ou texto sublime. Faça isso e quando eu for aqui, boom, se foi, apagado da história. Vamos tentar a soma ramificação agora. Obviamente, estou tendo um monte de problemas com esta próxima linha e estou usando um exemplo ridiculamente simplificado aqui. Mas isso é principalmente porque eu quero me concentrar em como se mover com essa linha do tempo em vez de aplicações práticas de codificação de código agora. Vamos fazer um ramo. Este é um exemplo perfeito de quando você pode querer usar uma ramificação se você está tentando evitar estragar as três linhas perfeitas que você tem até agora. Vamos abrir uma filial aqui. Faça isso, faça um git checkout -b. Ainda não verificamos o checkout, então vamos checar o checkout. Checkout é como você se move entre ramificações e git. Ele também pode ser usado como um comando abreviado para criar uma nova ramificação. Então, se eu disser git checkout -b, que é abreviação para branch, e dar-lhe um nome. Vamos chamá-lo de quarta linha. Veja isso, eu mudei para uma nova filial, quarta linha. Aqui estou eu, escreva aqui. Uma questão de fato, vamos chamar isso de A, salvá-lo e fazer um status git. Isso mostra que foi modificado principalmente porque eu acabei de mudar isso de um C para um A. Então vamos adicionar, olha para isso, isso é muito bom. Vamos em frente e cometa isso. Salve primeiro. Estamos a ver, está bem. Eu vou texto git add hello.txt, git commit -m, “Eu acho que eu tenho isso descoberto!” Lá vamos nós. Vamos fazer o registro do git. Verá todos os meus últimos compromissos aqui, incluindo o da nova filial. Agora estamos felizes com o poema. Mas estamos em uma nova filial. Por que não o fundimos no ramo mestre? Fazemos isso, agora vou colocar este diagrama vale a pena esperar. Vamos tentar trazer isso de volta aqui e fundi-lo e depois podemos continuar. Este padrão pode parecer familiar dois você embora, porque isso é exatamente o que olhamos nos slides lá. Nós vamos para aqui mesmo. Guarde isso. Vamos fazer git. Bem, agora fizemos mudanças, então vai querer que nos comprometamos novamente. Adicionar git commit, que é uma mensagem de commit bastante coxo. Não faça isso. Agora podemos git checkout master. Veja, vamos mudar para o mestre da filial. Agora veja o que acontece quando eu vou para hello.txt. Vai mudar de volta para onde paramos quando começamos nossa filial. Boom. Você vê isso? Então o mestre não está ciente do que temos feito naquela outra filial, na nossa linha do tempo alternativa. Para juntar essas duas coisas, vamos fazer um git. Fizemos checkout, vamos fazer uma fusão de git. O que chamamos a essa última filial, quarta linha. O que isso vai fazer, git vai fazer uma cópia desse ramo e mesclá-lo em mestre. Isto é o que eu faria se eu estivesse feliz com o que eu tinha feito na minha filial. Vamos tentar. Agora, quando eu for para cá. Boom, temos tudo no mestre. Então o círculo da vida continua. Eu posso continuar aqui e etc Isso é o básico do fluxo de trabalho git ali mesmo. Você cria algo, você comete, ação, backup. Você ramifica, você cria algo, você comete, você mescla de volta. Se eu fosse continuar assim, poderia subir aqui e começar outra filial aqui. Entende a ideia e continue assim. Esse é o básico do fluxo de trabalho. Ele só fica um pouco mais envolvido quando começamos a adicionar o GitHub e outras coisas mais tarde. Mas não muito. Se conseguires isto, ficas com o Git. Que tal isso para uma metade ou uma linha para embrulhar tudo. 6. Configure sua conta do GitHub: É hora de obter sua própria conta do GitHub. Eu só fui ao site do GitHub e preenchi minhas informações aqui. Agora eu tenho minha conta novata. Apenas pegue o de graça por enquanto. Se você quiser, você pode obter uma micro conta. Você não pode ter nenhuma conta privada no livre, todas elas têm que ser publicamente visíveis. Se você vai trabalhar em qualquer coisa que tenha algum material confidencial ou algo que você não tem, que você gostaria de ser capaz de esconder do mundo exterior, então você vai ter que pagar por isso. Mas, por enquanto, vou terminar isto aqui. Aqui estou eu. Vamos ver sobre isso, vamos dizer, “Não, obrigado.” Este é o seu painel que você obtém, e ele tem um pequeno passo por aqui que apenas leva você para os documentos e diz que é assim que você faz esse recurso, é assim que você faz isso. Vamos fazer isso agora mesmo. Vale a pena passar definitivamente. Certamente aprende alguma coisa. A primeira coisa que vamos fazer é analisar como você cria um novo repositório. Agora você fez isso localmente antes com o Git init em seu diretório e espaço de trabalho. Agora vamos fazer isso na Nuvem no GitHub e mostrar como você pode trazê-lo para o seu computador. Você também pode iniciar localmente e, em seguida, enviá-lo para o seu GitHub. Começou a recompra assim. Eu cubro isso em um minuto. Mas esta é provavelmente a maneira mais fácil de ir. Você clica no grande botão verde e o bom e velho GitHub diz: “Como você quer chamá-lo?” Este vai ser o repo para o nosso projeto. Vou chamar-lhe livro de receitas. Isso tem que ser público e eu vou clicar em “Inicializar este repositório com um README”. Vou te mostrar o porquê em um minuto. Lá vamos nós. Aqui está o meu novo repositório de livros de receitas. Este é o arquivo README por padrão, quando você chega à página da sua conta do GitHub. Você pode conferir isso acessando qualquer outro repositório do GitHub na Internet. Ele mostra este arquivo Readme.md e MD significa markdown. Markdown é uma forma abreviada de escrever HTML. O GitHub entende isso e irá analisá-lo e escrevê-lo assim. Vamos trabalhar neste arquivo README para esta classe. Vá em frente, obtenha uma configuração de conta do GitHub e nós vamos voltar aos slides e falar um pouco sobre as maneiras como vamos interagir com o GitHub e começar a compartilhar conteúdo um com o outro. Na verdade, estamos chegando perto do final da lição, temos mais algumas unidades para ir, mas eu diria que já passamos do meio do caminho e é aqui que vai se divertir. Pegue sua conta e te vejo no próximo vídeo. 7. Clonagem e de a clonagem e a de Cloning e a de a de: Aqui vamos nós. Vamos dar uma olhada no GitHub. GitHub é essencialmente apenas um repositório Git que está disponível no github.com. GitHub criou um conjunto de recursos que ajudam você a trabalhar em projetos baseados em equipe. É também uma rede social para projetos de código aberto. Dois dos principais componentes do fluxo de trabalho do GitHub são clonagem e bifurcação. Clonagem é basicamente apenas fazer uma cópia. É como o que parece, o que você quer fazer é transferir coisas do seu repositório do GitHub para o seu ambiente de desenvolvimento local para que você possa trabalhar neles. Quando você faz essa cópia, GitHub nomeia automaticamente essa origem de repositório. É um controle remoto. Como você pode ver, ele está longe de seu ambiente de desenvolvimento local. Agora, você ainda tem um repositório Git como já vimos antes localmente e você pode contar sobre qualquer número de controles remotos. Em um projeto, você pode ter um controle remoto para implantar código de teste, você pode ter um para implantar código de produção, você pode até mesmo fornecer a outros computadores membros da equipe um endereço remoto e código de push para eles. Estes são chamados de controles remotos. Aqui você verá uma versão um pouco diferente dessa ramificação, criar, confirmar, mesclar, ciclo que já vimos antes. Quando chegarmos ao nosso commit e estivermos prontos para fundi-lo, em vez de fundi-lo de volta ao nosso ramo mestre, o que vamos fazer é empurrar esse conteúdo para o nosso controle remoto e fundi-lo lá. Quando isso for mesclado com o ramo mestre, vamos então puxar esse novo ramo mestre de volta para o nosso projeto e começar esse ciclo novamente. E se for outra pessoa GitHub repo? Você não terá acesso a ele. A não ser, é claro, que sejas administrador nesse projecto. O que acontece quando você tenta enviar conteúdo para esse repositório? Bem, você não será capaz porque você não tem direitos de acesso. Nesta condição, você terá que enviar o que é chamado de pull request. Essencialmente, um pull request é apenas um aviso que você dá a quem possui esse repositório que diz: “Ei, eu criei esse conteúdo. Você vai puxá-lo para o projeto?” A função que eles servem é que, essencialmente, mantém todos no mundo de empurrar conteúdo para o projeto de um proprietário sem sua permissão. Em um projeto baseado em equipe, ele também dá um conjunto extra de olhos para o código que está sendo contribuído e que geralmente codificará conteúdo. Outra pessoa terá que rever o que vai ser enviado e aceitá-lo para inclusão. Então é um bom filtro para manter as coisas limpas. Uma pequena nota; quando você enviar pull requests, tente mantê-los o mais concisos possível. Não faça uma tonelada de trabalho para quem vai ter que rever este pedido pull. Felizmente, os outros membros da sua equipe vão estender a mesma cortesia para que você não tenha ler através de um pull request gigantesco apenas para incluí-lo no projeto. Agora, se essa solicitação pull for aprovada, o processo continuará da mesma maneira que vimos. Ele seria mesclado no ramo mestre e você puxaria esse novo mestre para baixo e incorporá-lo em seu projeto. Só que agora, ele pode conter submissões de outros membros da equipe. Assim, você obteria não apenas o seu recurso, mas quaisquer outros recursos foram desenvolvidos enquanto você está trabalhando no seu. bifurcação é um pouco como clonagem. É só fazer uma cópia do repo de outra pessoa lá em cima no GitHub. Você começa com o repositório do GitHub, você faz o fork e agora você tem o repositório do GitHub e seu repositório do GitHub. bifurcação funciona bem quando você quer pegar um projeto de código aberto, torná-lo seu próprio e levá-lo em sua própria direção. Em um projeto, muitas vezes vou bifurcar o repo para que eu tenha essa medida adicional de revisão. Vou empurrar minha filial lá em cima, revisá-lo, e depois enviar um pedido de pull para o repositório principal. Você recebe um pouco de magia do GitHub quando você faz isso. Os dois repos estarão cientes um do outro. GitHub desenvolveu vários recursos que fazem a revisão e mesclagem de código ou conteúdo. Eu uso código e conteúdo de forma intercambiável. Ele vai fazer coisas, como deixar você saber se os pedidos ruins podem ser mesclados facilmente ou se há algum problema. Você verá um pouco mais sobre isso quando eu guiar você através do exemplo ao vivo. Vamos juntar tudo isso e você verá como funciona, o local e o controle remoto. Vai incorporar todas as coisas sobre as quais falamos até agora. Falamos sobre o Git, sobre controle de versão distribuída, instalamos o Git, inicializamos um repositório Git localmente. Analisamos ramificação, encenação e comprometimento. Sabemos o que é a HEAD e sabemos o que é a fusão. Falamos sobre empurrar, o que são controles remotos, clonagem, bifurcação e solicitações pull. Vamos ver como essa coisa toda funciona em conjunto. Vamos começar com um projeto mestre. Vamos bifurcá-lo e ter nosso próprio repositório, que então clonaremos para nossos ambientes locais para que possamos trabalhar nele. Faremos nosso trabalho, empurraremos até nosso garfo e enviaremos uma solicitação de pull para o repositório principal do projeto. Quando estiver tudo bem, podemos retirá-lo localmente com quaisquer alterações que tenham sido enviadas por outros membros da equipe. Esse ciclo só se repete e se repete. Então prepare-se. Vamos fazer isso ao vivo agora. Após este próximo vídeo, você deve estar pronto para contribuir para o nosso projeto. 8. Clonagem de um rede do GitHub - demonstração ao vivo: Vamos começar com uma demonstração ao vivo. Aqui estou eu no meu novo repositório do GitHub que configurei, especialmente para este projeto. Estou chamando de “cozinhar com Marc”. É aqui que vou guardar algumas das minhas receitas. Eu não tenho nenhum repositório, então vamos começar um novo agora mesmo. Vamos chamar isso de brinde, e eu vou colocar minha receita de torrada aqui. Vai ser padrão para público. Se você quer um repo privado, você tem que pagar por ele. Então vamos a público já que quero compartilhar minha receita de torrada com o mundo. Vou inicializar isso com um arquivo README, o que é uma boa idéia. Pelo menos o repositório tem algo nele. Em seguida, basta clicar no grande botão verde, e lá vamos nós. Agora, nós vamos para aqui. Vou clonar isto no meu ambiente de desenvolvimento local. Você pega o clone e cola esse endereço lá. Lembra do controle remoto da última série de slides? Este é o controle remoto aqui em que estou. Então eu tive que clonar isso para a minha área de trabalho, e assim que eu fizer isso, Git vai escrever em seu endereço remoto. Deixe-me fazer isso, vai fazer mais sentido. Então ele o trouxe para baixo, vamos verificar a janela do Finder aqui, e ele deve nos dizer, com certeza, que há torradas. Então, se eu disser git remoto, eu preciso mudar diretórios para o repositório real agora. Faço isso em todos os projetos. CD no brinde. Agora eu faço git remoto, e ele vai me mostrar a origem. Então esse é o controle remoto que eu tenho, nomes na origem por padrão, você pode alterá-lo para qualquer coisa que você quiser. Eu gosto de seguir a convenção de nomes de origem e upstream, só porque isso me ajuda a manter claro em minha mente onde exatamente eu estou empurrando conteúdo para mais tarde. Agora eu posso fazer um git remoto -v para verbose. Essa bandeira significa ser detalhado, diga-me mais. Então você verá que a origem tem este endereço, cookingwithmarc/toast.git, que é o que copiamos colado. Então você pode usar essas origens ou esses controles remotos. Você informa esses endereços ao repositório do GitHub e ele permitirá que você envie conteúdo para eles. Posso enviar para o meu repositório do GitHub. Posso colocar o endereço do repo de outra pessoa lá, e adiar. Essa é uma maneira muito legal. Está no centro dessa noção de controle de versão distribuída. Vamos dar uma olhada no arquivo README, vamos fazer algumas edições aqui. Este é um arquivo Markdown, md significa Markdown. É uma maneira de escrever HTML em abreviação. Então, se você estiver familiarizado com H1, H2, H3 como níveis de cabeçalho, mesmo que você tenha trabalhado apenas em um aplicativo de documento de processamento de texto antes, você está familiarizado com essa idéia. Então você pode dizer Markdown para renderizar um H1 com uma hashtag, duas hashtags como um H2, três como H3 etc Aqui estão meus ingredientes. Vamos fazer isso como um H3. Qualquer lugar que tenha uma quebra de linha, vai renderizar como um novo parágrafo. Vamos ver, eu tenho minha direção de brinde aqui? Eu guardo isso. Vamos até aqui, e vamos fazer todo esse ramo criar processo de submissão de estágio. Eu já comecei a criar sem iniciar uma nova ramificação. Então vamos começar uma nova filial. Vamos chamar essa saída de receita. Git checkout -b para receita de ramo. Então, se fizermos um status de git, ele diz que o README foi modificado, e você pode ver aqui quando começamos o branch, nós carregamos esse README modificado para ele. Então eu vou dizer git add, readme.markdown, fazer um git commit -m para mensagem. Status rápido do git até que tudo esteja legal. Então agora eu vou empurrar isso para o meu repo de origem. Então eu vou dizer git empurrar para a origem. O que chamamos a esta filial? Receita. Lá vamos nós. GitHub vai me pedir para autenticar com o nome de usuário e senha toda vez que eu empurrar. A menos que eu tenha configuração SSH, que é um nível adicional de segurança. Eu não vou falar disso agora, isso pode ser um tópico para outra aula. Você veio no Google como configurar SSH, não é tão difícil. Então, se você estiver digitando seu nome de usuário e senha várias vezes, pesquise isso e veja se consegue fazê-lo funcionar. Geralmente é o que eu uso. Então vamos para a conta do GitHub agora. Você verá que eu tenho um pedido de pull aqui. Assim que eu enviar esse conteúdo, GitHub reconheceu que era uma nova ramificação recebida, e ele diz: “Você quer fazer uma solicitação pull para isso?” Claro. Vamos criar a solicitação pull. Então agora ele vai me dizer, você pode mesclar isso automaticamente. Isso é ótimo, vamos fazer isso. Vamos fundi-lo, firme-lo. Ótimo. Então o que é feito é a mesma coisa que faríamos localmente quando nos fundimos de volta. Você vai até aquele galho pequeno e então quando você terminar de se comprometer, você se fundiu de volta ao mestre. Acabamos de fazer isso aqui na Nuvem no nosso repositório do GitHub. Então você pode excluir o ramo que você empurra porque ele foi puxado para o seu mestre. Agora, vamos descer aqui. Se dissermos git, quero mostrar-te isto. Nossa receita de torrada é toda em uma peça. Ainda estamos no ramo das torradas. Então, se eu disser git checkout, mestre, veja o que acontece. Uau, tudo se foi. Então esse ramo tem todas essas mudanças, o mestre não tem. Se estivéssemos trabalhando localmente, mesclaríamos o ramo de receita em mestre. Bem, vamos fazer isso a partir do repositório do GitHub. Então eu digo git pull, e o que pull faz, é ele sobe, olha ao redor para qualquer coisa nova, trazê-lo para baixo e funde-o com qualquer ramo aqui dentro. Então git pull origem, mestre. Lá vamos nós, e agora devemos ter todas essas mudanças. Então há um loop através do buraco, criando um repositório, clonando-o para baixo, criando conteúdo, empurrando-o para cima, mesclando-o e trazendo-o de volta para baixo, e complete o conjunto que você viu nos slides. Então, para o próximo vídeo, eu vou fazer a mesma coisa com bifurcação. É apenas mais um pouco adicional de complexidade honestamente. O que eu quero que você faça é tentar isso, e faça todo esse circuito funcionar para você. Este é o seu GitHub básico e Git Workflow que você usaria em qualquer tipo de projeto web, ou projeto de código aberto, ou qualquer coisa assim. Então, se você pode fazer isso, você tem, e a próxima lição será apenas um pouco extra. Então tenha isso e boa sorte. Te vejo em um minuto. 9. Forking um repo do GitHub - demonstração ao vivo: Agora, vamos olhar para bifurcação no GitHub. Isso é típico do processo que você passaria se você quisesse contribuir para um projeto que você não possui. Este é o meu repo pessoal no GitHub. Tenho outro navegador aberto com o nosso livro de receitas. Enquanto eu estiver logado aqui como administrador neste navegador, eu não estou, mas eu posso navegar até ele. Vamos para github.com/gitforvisual. Posso seguir essa pessoa até aqui, e também posso ver os repos que eles têm. Uma vez que isto é público, eu posso desviá-lo. Aqui está o ícone do garfo. Quando faço isso, adoro esta animação aqui. Recebi um garfo do GitHub. Lá vamos nós. Cozinhando comMarc/livro de receitas. Isto vai ser uma cópia do que está aqui. Veja como eles combinam. Agora, eu preciso seguir o mesmo procedimento que eu fiz quando eu estava clonando. Copiei esse URL, volto aqui, certifico-me de que estou no espaço de trabalho e digo “obter clone”, colocar isso dentro. Lá vamos nós. Agora eu deveria ter livro de receitas no espaço de trabalho. Lá está ele. Agora eu posso pegar esse arquivo README e editá-lo. Isso vai realmente fazer parte do nosso projeto. Mais uma vez, eu fiz o que você não deveria fazer, que é começar a criar antes de criar uma ramificação. Deixe-me fazer isso agora. Um status rápido do git vai nos mostrar. Tenho que ver no livro de receitas. Lá vamos nós. Status do Git. Git checkout-b, vamos chamar este ramo de tortilla. Git adicionar o arquivo Readme.markdown, git confirmá-lo com uma mensagem. Lá vamos nós. Agora eu posso fazer uma tortilla origem git push. Isso vai empurrar minha filial localmente para o meu repositório do GitHub. É aqui que vamos ver a magia do GitHub entrar com o garfo. Eu faço isto. Agora vamos dar uma olhada. Claro o suficiente. Ali está o meu ramo que eu empurrei lá em cima. Quando eu digo compare e pull request, ele me dá a opção de criar um pull request. Não vejo nada aqui que diga como fundi-lo. Porque agora estou no Git para visual/livro de receitas. Siga esse link mágico do meu repositório do GitHub para o que eu bifurquei. Agora, se eu passar aqui para o Git real para repositório visual do livro de receitas que eu estou logado como um administrador em e olhar na solicitação pull, é aí que a solicitação pull aparece. Agora posso revisá-lo e posso fundi-lo. Torna-se parte deste repositório. Vamos voltar aqui. Lá vai você. Como antes, se eu for git checkout master, tudo isso deve desaparecer. Boom. Temos que puxar a versão mais atualizada do mestre para o nosso repositório. Git, puxe. Espere um minuto. Espere um segundo. Vamos ver nossos controles remotos. Só temos uma origem. Precisamos adicionar um controle remoto para o livro de receitas original. Vamos voltar para lá. Copie o URL do clone e diga, “Git remote add upstream” e cole isso em. O que eu estou dizendo é, “Ei git, eu quero adicionar um controle remoto, eu quero chamá-lo de upstream.” Mais uma vez, posso chamar-lhe o que eu quiser. Mas a montante e a origem são duas convenções de nomenclatura que eu cumpro e que muitas pessoas seguem porque isso ajuda você a separar em sua mente onde você está empurrando essas coisas. O Origin é meu e o upstream é o principal repositório canônico do GitHub. Vou dizer “Enter”. Agora, se eu disser git remote-b, ele me mostra minha origem e meus controles remotos upstream. Se eu disser git pull upstream master, ele vai subir para upstream, ele vai olhar em volta para qualquer coisa nova, ele vai puxá-lo para baixo e vai fundi-lo com o meu ramo mestre. Quando eu voltar aqui, eu deveria tê-lo agora. Boom, lá vamos nós. Agora, eu posso começar todo o ciclo de novo. Se você pressionar Comando K, ele limpa a tela. Gosto de fazer isso com bastante frequência. Eu vou git checkout-b. Digamos que eu queira fazer alguns ajustes na forma como escrevi minha receita. Quando eu começar este ramo de ajustes, Eu tenho o mais recente e o maior mestre. Se eu estivesse colaborando e isso vai acontecer enquanto colaboramos, eu vou puxar todas as mudanças que foram adicionadas por outros membros da equipe, bem como apenas a minha. Quando começo uma nova filial, trago todos com ela. Eu sempre tenho a versão mais atualizada. Eu tenho um novo ajuste de filial. Vamos entrar aqui. Eu só vou fazer isso uma pequena atualização. dizer uma coisa, eu também vou colocar uma linha aqui para separar minha receita de todos os outros. Esses são os meus ajustes. Git add é um truque. Git add. adiciona todos os seus documentos no palco. Se você tem um monte de coisas abertas , pode ficar um pouco complicado. Mas se você está normalmente trabalhando em três ou quatro arquivos, que você será se você estiver fazendo desenvolvimento web, isso é legal e é um pedaço de abreviação que permite adicionar vários de cada vez sem digitar todo o nome do arquivo. Git commit m para mensagem, mudou algum texto. É uma mensagem muito pobre, mas vamos continuar com ela. Agora eu posso fazer uma origem git push. Vamos chamar isso de ajustes. Eu empurrei isso para cima, vamos dar uma olhada. Onde está o meu repo? Se eu solicitar ajustes, ele me salta aqui, eu crio o pull request, ele só pode ser mesclado por colaboradores do projeto. Bem, vamos até aqui onde eu sou um colaborador e olhar para os pedidos pull. Lá está ele. Estou fundindo-o como administrador aqui. Agora eu posso dizer git checkout master. Eu posso puxar. Vamos checar isso bem rápido. Estou no mestre, então minhas mudanças não deveriam estar aqui e não estão. Desde que eu git pull master upstream, ele vai obter as últimas alterações e isso agora deve refletir as pequenas mudanças que eu fiz. Há alguns loops através da bifurcação. Basicamente é isso. Você está no fim desta aula. Você cobriu bastante material e agora você deve ser capaz de configurar seu próprio repositório Git localmente. A configuração foi para cima no GitHub e clone e fork. Essas são as habilidades básicas que você precisa para colaborar com um projeto de equipe usando o Git. Parabéns, definitivamente passar por isso um par de vezes. Então vamos fazer o vídeo final sobre o que enviar para o seu projeto de receita, que você praticamente acabou de ver. Se você pode colocar uma receita lá em cima, então você fez isso. Esse é o objetivo. Não há muito trabalho duro até criar algum artefato, maior parte do trabalho duro que você fez nesta classe é apenas aprender. Aprender como as coisas funcionam e aprender a sintaxe e o protocolo para contribuir. Parabéns e te vejo no vídeo final. 10. Mescla conflitos e atribuição final: Tudo bem, todo mundo. Bem-vindo ao último vídeo para Git e GitHub para alunos visuais. Eu vou cobrir algo muito rápido que você provavelmente não vai encontrar no curso deste projeto. Mas se você começar a usar o Git de qualquer forma baseada em equipe, há uma boa chance de você encontrar o que é chamado de conflito de mesclagem. Você pode ver que eu entrei e estraguei o arquivo para que eu pudesse criar esse conflito de fusão. Basicamente, o que acontece é que, quando você tem pessoas contribuindo e, em seguida, puxando para baixo e re-contribuindo e puxando para baixo naquele ciclo, mais cedo ou mais tarde alguém vai alterar algum código em uma linha que outra pessoa fez, e isso pode confundir o Git. O Git pode não saber qual versão das duas alterações diferentes tomar. Por isso, dá-te um conflito de fusão. Mas ele vai fazer algo útil para você, ele vai apontar onde está a confusão. Então aqui você vê uma seleção, onde em um caso alguém enviou o nome Marc Nischan Esquire, e o outro Marc Nischan PhD. Então Git envolveu isso em um pequeno comentário. Você verá esse padrão distinto de maiores thans e menos thans divididos por uma linha sólida. Então Git está dizendo que este grande número é o ID real do commit. Então Git está dizendo, entre esses dois, qual deles você quer manter, essencialmente? Então tudo que você tem que fazer é consertar isso. Vou ficar com o Esquire. Embora, eu não seja nem um Esquire nem PhD. Mas essa é uma história completamente diferente. Então eu pareço isso para ser apenas os textos que eu quero manter, e havia outro aqui em baixo, parece que esses espaços foram alterados. Isso não faz muito sentido, vamos nos livrar disso também. Então agora eu posso salvar isso. Vamos fazer um status Git e ver o que eu recebo. Ótima. Git adicionar. Git commit -M, mensagem, resolvendo um conflito de mesclagem. Lá vamos nós. Então, é uma rápida olhada em conflitos de fusão. Outra opção que você tem é baixar uma ferramenta de mesclagem. Eu uso P4Merge, é grátis. É muito bom. Você pode ver nesta foto aqui, basicamente alinha o que está no controle remoto, o que está no seu computador, e o que está no ramo que você puxou para baixo. Ele pede que você escolha entre as diferentes versões, e salva a que você escolher. Então essa é uma maneira visual muito legal de passar por essas coisas. Ele permite que você percorra todo o documento e mostra todos esses lugares diferentes onde os erros estão. Não quero instalá-lo. Há alguns grandes tutoriais lá fora sobre como instalar esta coisa. Há um monte de ferramentas de mesclagem livre. Então olhe em volta, escolha um que você gosta, e você pode fazer isso funcionar, eu tenho certeza muito rápido. Então agora o que eu quero fazer é percorrer um ciclo inteiro. Basicamente, este é o seu projeto final. Todo o ciclo de adicionar uma receita, e comprometê-la localmente e empurrá-la para inclusão no livro de receitas mestre. Então, aqui vamos nós. Então aqui está o meu projeto, projeto de livro de receitas. Vou adicionar outra receita. Isso é o que você faria. Você começaria por bifurcação, clonagem e, em seguida, começando em uma nova ramificação. Então, estou no mestre agora. Posso verificar isso indo para o status do Git. Vamos fazer um checkout Git B e vamos chamar este novo ramo, alho. Porque eu vou adicionar receita para alho assado. Então vamos até o fim do meu último. Bem aqui, tem um monte de formatado em Markdown. Então não teremos que perder tempo. Lá vamos nós. Então salve-o, e eu preciso adicioná-lo, confirmá-lo. Agora vou empurrar isso para a minha versão bifurcada disto. Estou usando a convenção de nomes de origem e montante. montante é o original, e a origem é a que eu bifurquei. Então nós vamos empurrar essas mudanças para cima Git. Empurre cabeça de origem. Então empurre para a origem onde eu estou agora. Lá vamos nós. Agora, como eu vou para o meu repositório, aqui, livro de receitas, eu tenho a opção de fazer um pedido de comparação e pull, o que eu vou fazer. Ótima. Está atualizado com a filial base, então eu não deveria ter problemas em fundir isso. Então agora eu vou voltar para este outro navegador onde eu estou logado como administrador, e eu vou olhar para os pull requests, e lá está ele. Então é isso que vou fazer quando receber o seu pedido. Eu vou olhar para ele, verificar os arquivos, ter certeza de que não há nada louco lá dentro. Agora você vai notar esses ícones aqui. Eles deixaram você ver o arquivo completo. Basicamente esconde coisas que não têm conflitos, coisas que você já viu antes. Isso torna mais fácil para digitalizar as alterações e não ter que se preocupar com todo o texto entre eles. Bem, isso tudo parece bom. Vamos voltar e fundir isso. É isso. Então você não vai mesmo ter que fazer este passo, tudo que você realmente tem que fazer é empurrá-lo para cima, e deixar o pull request chegar através deste repositório, em que ponto eu realmente vou adicioná-lo ao livro de receitas. Mas o que você pode fazer quando você vai para o Skillshare para o seu projeto final, é apenas tirar uma imagem de sua versão, seu perfil disso. Basta tirar uma captura de tela e postar isso como o projeto final. Isso deve bastar. Muito obrigado por fazer esta aula, eu realmente agradeço. Se você achou útil, uma avaliação positiva realmente torna essa classe mais fácil para outras pessoas encontrarem, deixa-a flutuar um pouco para o topo. Então, se você achou útil, por favor, dê uma avaliação positiva e ajude outras pessoas a encontrá-la. Claro, se você tiver algum feedback, positivo ou negativo, eu adoraria ouvir. Então talvez eu possa fazer esta aula um pouco melhor. Obrigado novamente e boa sorte. Uma última coisa que eu quero dizer é que, eu coloquei gitforvisual.com. Como você pode ver, não há muita coisa lá agora. Mas o que ele tem, é este PDF que você pode baixar. Basicamente, é uma folha de truques que percorre todo esse processo que passamos juntos aqui na classe. Isso é algo que você pode manter à mão se você quiser apenas uma referência rápida para o fluxo de trabalho que descrevemos. Então, aí está. Mais uma vez, muito obrigado. Agradeço o seu feedback e aproveite o Skillshare e o Git. Muito obrigado. Tchau.