WIP: A descrição e explicação dos comandos está sendo postada aqui conforme o avanço.

levels

Remote

Módulo: Push & Pull - repositórios remotos no Git!

1: Introdução a clonagem

Dificuldade (pra mim!): fácil

• Repositórios remotos não são algo muito complicado. Nos dias atuais de computação em nuvem, seria fácil pensar que existiria muita mágica por trás dos remotos do Git, mas não é o caso -- eles são na verdade apenas cópias do seu repositório em outro computador. Você pode geralmente comunicar-se com esse outro computador por meio da Internet, o que permite que você transfira commits de um lado para o outro.
• Tendo dito isto, repositórios remotos tem uma série de propriedades interessantes:
  • Primeiro e antes de tudo, repositórios remotos servem como um ótimo backup! Repositórios Git locais possuem a habilidade de restaurar um arquivo para um estado anterior (como você sabe), mas toda a informação está guardada localmente. Tendo cópias do seu repositório Git em outros computadores, mesmo se você perder todos os seus dados locais, ainda terá como recomeçar do mesmo ponto de onde você tinha parado.
  • Ainda mais importante, repositórios remotos tornam o desenvolvimento uma atividade social! Agora que uma cópia do seu projeto está hospedada em outro lugar, seus amigos podem contribuir para o seu projeto (ou obter as suas últimas alterações) de uma forma bastante simples.
• Está se tornando bastante popular o uso de websites para visualizar a atividade em repositórios (como o GitHub), mas o recurso de repositórios remotos sempre serve como mecanismo base para essas ferramentas. Então é importante entender como ele funciona!
• Até este ponto, o Learn Git Branching focou em ensinar o básico a respeito de trabalho em repositórios locais (branch, merge, rebase, etc). Entretanto, agora que queremos aprender como repositórios remotos funcionam, precisamos de um comando para configurar o ambiente para essas lições. Esse comando será o git clone.

2: Branches remotos

Dificuldade (pra mim!): fácil

• Agora que vimos o git clone em ação, vamos estudar aquilo que realmente mudou.
• A primeira coisa que você pode ter percebido é que um novo branch chamado o/main aparece no nosso repositório local. Esse tipo de branch é chamado de branch remoto; branches remotos possuem propriedades especiais pois eles servem a um propósito único.
• branches remotos refletem o estado de repositórios remotos (desde a última vez na qual você falou com eles). Eles ajudam a entender as diferenças entre o trabalho local e o trabalho atualmente público -- um passo crítico a ser dado antes de compartilhar seu trabalho com os outros.
• branches remotos possuem a propriedade especial de, ao sofrerem um checkout, colocarem o repositório em modo "Detached HEAD". O Git faz isso de propósito, porque você não pode trabalhar nesses branches diretamente; você é obrigado a trabalhar em outro lugar e só então compartilhar seu trabalho com o remoto (depois disso, os branches remotos serão atualizados).
• O que é o/? Você pode estar se perguntando o que o o/ no início do nome dos ramos remotos significa. Bem, ramos remotos possuem uma convenção obrigatória de nomes -- eles são mostrados no seguinte formato:

<nome do repositório remoto>/<nome do ramo>

• Então, se o ramo remoto é chamado o/main, o nome do ramo é main e o nome do repositório remoto é o.
• A maioria dos desenvolvedores na verdade chama o repositório remoto principal de origin, e não de o. Isso é tão comum que o Git define por padrão o nome origin para o repositório remoto quando você usa o comando git clone para clonar um repositório.

3: Git fetch

Dificuldade (pra mim!):

• Trabalhar com remotos no Git, no final das contas, se resume a transferir dados de e para outros repositórios. Desde que possamos enviar commits para um lado e para o outro, poderemos compartilhar qualquer tipo de atualização que seja gerenciada pelo Git (e portanto compartilhar trabalho, novos arquivos, novas ideias, cartas de amor, etc).
• Nesta lição vamos aprender como baixar dados de um repositório remoto -- o comando para isso é convenientemente chamado de git fetch.
• Você perceberá que conforme atualizarmos a representação do repositório remoto, nossos ramos remotos atualizar-se-ão para refletir essa nova representação. Isso tem a ver com o que vimos na lição anterior sobre ramos remotos.
• O git fetch realiza dois passos principais, e somente estes dois passos principais. Ele:
• Baixa os commits que o repositório remoto possui mas que estão faltando no repositório local, e... Atualiza a referência para a qual os ramos remotos (por exemplo, o/main) estão apontando O git fetch essencialmente faz com que nossa representação local do repositório remoto fique sincronizada com a forma com que o repositório remoto de fato se parece (naquele momento).
• Se você lembrar da lição anterior, nós dissemos que os ramos remotos refletem o estado dos repositórios remotos desde a última vez na qual você falou com esses repositórios. O git fetch é a única forma de falar com esses repositórios remotos! Espero que a conexão entre os ramos remotos e o git fetch esteja clara agora.
• O git fetch geralmente conversa com o repositório remoto por meio da Internet (usando um protocolo como http:// ou git://).
• O git fetch, no entanto, não muda nada do estado local do repositório. Ele não atualiza o seu ramo main nem muda nada na forma como o seu sistema de arquivos está no momento.
• É importante entender isso, pois muitos desenvolvedores pensam que executar git fetch fará com que o trabalho local reflita o estado do repositório remoto. Ele pode até baixar todos os dados necessários para fazê-lo, mas ele não muda de fato nenhum dos arquivos locais. Vamos aprender comandos para fazê-lo nas lições a seguir :D
• No final das contas, você pode pensar no git fetch como um passo de download.

4: Git pull

Dificuldade (pra mim!):

• Agora que vimos como baixar dados de um repositório remoto com git fetch, vamos atualizar nosso trabalho para refletir essas mudanças!
• Há, na verdade, muitas formas de fazê-lo -- uma vez que você tenha os novos commits disponíveis localmente, você pode incorporá-los como se eles fossem commits normais em outros ramos. Isso significa que você pode executar comandos como estes a seguir:

git cherry-pick o/main

git rebase o/main

git merge o/main

• O fluxo de trabalho de executar fetch para baixar as mudanças remotas e depois fazer um merge delas é tão comum que o Git na verdade fornece um comando que faz ambas as coisas de uma vez só! Esse comando é o git pull.

5: Simulando trabalho em equipe

Dificuldade (pra mim!):

• Neste ponto, temos uma pequena dificuldade -- para algumas das lições a seguir, precisaremos ensinar como fazer pull de mudanças que foram introduzidas no repositório remoto.
• Isso significa que precisaremos essencialmente "fingir" que o repositório remoto foi atualizado por algum de seus colegas / amigos / colaboradores, algumas vezes em um ramo específico ou com um certo número de commits.
• Para esta finalidade, criamos o comando fictício git fakeTeamwork! Ele é bastante auto-explicativo, vejamos uma demonstração...

6: Git push

Dificuldade (pra mim!):

• Ok, então vimos como baixar mudanças do repositório remoto e incorporá-las à árvore local. Isso é ótimo e tal... mas como eu faço para compartilhar o meu trabalho sensacional com as outras pessoas?
• Bem, a forma de subir trabalho a ser compartilhado é a oposta daquela de baixar trabalho que foi compartilhado. E qual o oposto de git pull (puxar)? É git push (empurrar)!
• O git push é responsável por subir as suas mudanças para um repositório remoto especificado, e atualizar esse remoto para incorporar seus novos commits. Uma vez que o git push se completa, todos os seus amigos podem baixar o seu trabalho do repositório remoto.
• Você pode pensar no git push como um comando para "publicar" o seu trabalho. Ele tem uma série de nuances que vamos abordar em breve, mas comecemos com passos curtos...
• Nota -- o comportamento de git push sem argumentos varia dependendo da configuração push.default do Git. O valor padrão para essa configuração depende da versão do Git que você estiver usando, mas vamos assumir o valor upstream nestas lições. Isso não é um grande problema, mas vale a pena verificar suas configurações antes de fazer push nos seus próprios projetos.

7: Histórico Divergente

Dificuldade (pra mim!):

• Imagine que você clonou um repositório na segunda-feira e começou a trabalhar em uma funcionalidade nova. Na sexta-feira você está pronto para publicar a funcionalidade -- mas, ah não! Seus colegas escreveram um bocado de código durante a semana, tornando a sua funcionalidade obsoleta. Eles também publicaram esses commits no repositório remoto que vocês compartilham, então agora o seu trabalho é baseado em uma versão antiga do projeto, que não é mais relevante.
• Neste caso, o comando git push é ambíguo. Se você executar git push, será que o Git deveria tratar o repositório remoto como se ele ainda estivesse no estado da segunda-feira? Será que ele deveria tentar adicionar seu código dentro do repositório sem tentar remover o código novo? Ou será que ele deveria simplesmente ignorar suas mudanças totalmente, já que elas estão obsoletas?
• Devido à grande ambiguidade que surge neste tipo de situação (quando a história divergiu), o Git não permite que você faça push das suas mudanças. Ele, de fato, força você a incorporar o último estado do repositório remoto antes de conseguir compartilhar o seu trabalho.
• Como resolver essa situação? É fácil, tudo que você precisa fazer é basear seu trabalho na versão mais recente do ramo remoto.
• Existem algumas maneiras de fazer isso, mas a mais direta é mover o seu trabalho usando rebase.
• Vamos fazer a mesma tarefa usando merge em vez de rebase.
• Embora o git merge não mova o seu trabalho (em vez disso, ele cria um commit de merge), ele é uma forma de contar ao Git que você incorporou todas as mudanças do repositório remoto. Isso acontece porque o ramo remoto passa a ser um ancestral do seu próprio ramo, significando que o seu commit reflete todos os commits contidos no ramo remoto.
• Você já conhece o git pull e ele é simplesmente um atalho para um fetch e um merge. Convenientemente, entretanto, o comando git pull --rebase é uma abreviação para um fetch e um rebase!

8: Main bloqueado

Dificuldade (pra mim!):

• Se você trabalha em uma grande equipe colaborativa é provável que o main seja bloqueado e precise de alguns processos de Pull Request para unir mudanças. Se você commitar diretamente para o main localmente e tentar fazer um push você visualizará uma mensagem similar a essa:

! [remote rejected] main -> main (TF402455: Pushes to this branch are not permitted; you must use a pull request to update this branch.)

• O repositório remoto rejeitou o push dos commits diretamente para o main por causa da política do main necessitando do uso dos pull requests.
• Você pretendia seguir o processo de criação de uma ramificação, fazendo um push dessa ramificação e fazendo um pull request, mas você esqueceu e commitou diretamente para o main. Agora você está preso e não consegue publicar suas mudanças.