DEV Community: Vitor Jr.

Aprendendo Git Branching - Push & Pull - repositórios remotos no Git!

Vitor Jr. — Fri, 09 Jun 2023 13:53:39 +0000

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.

Aprendendo Git Branching - Temas Avançados

Vitor Jr. — Fri, 09 Jun 2023 12:07:58 +0000

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

levels

Main

Módulo: Temas avançados

1: Fazendo mais de 9000 rebases

Dificuldade (pra mim!): dificil

Essa lição é mais um cenário proposto que diz:

Cara, temos um monte de branches aqui! Vamos fazer um rebase de todo o trabalho contido nesses branches para o main.

No entanto, a cúpula da administração está tornando as coisas mais difíceis -- eles querem que os commits estejam todos em ordem sequencial. Isso significa que a nossa árvore final precisa ter o C7' por último, C6' acima disso, e assim por diante, tudo ordenado.

Se você fizer besteira, sinta-se livre para usar o comando reset para recomeçar do zero. Depois lembre de olhar nossa solução do gabarito para ver se consegue resolver a tarefa usando menos comandos!

Comandos:

# 1
git rebase main bugFix

# 2
git rebase bugFix side

# 3
git rebase side another

# 4
git rebase another main

2: Especificando pais

Dificuldade (pra mim!): fácil

Essa lição é mais um cenário proposto que diz:

Assim como o modificador ~, o modificador ^ também aceita um número opcional depois dele.

Em vez de especificar o número de gerações a voltar (que é o que o ~ faz), o modificador no ^ especifica qual referência de pai a ser seguida a partir de um commit de merge. Lembre-se que commits de merge possuem múltiplos pais, então o caminho a seguir é ambíguo.

O Git normalmente subirá o "primeiro" pai de um commit de merge, mas especificar um número após o ^ muda esse comportamento padrão.

Basta de conversa, vejamos o operador em ação.

Comandos:

# 1
git branch bugWork mmain~^2~

3: Espaguete de branches

Dificuldade (pra mim!): fácil

Essa lição é mais um cenário proposto que diz:

Uhuuuuu Nelly! Temos um belo de um objetivo para alcançar neste nível.

Temos aqui um main que está alguns commits atrás dos branches one, two e three. Seja lá por qual razão, precisamos atualizar esses três outros branches com versões modificadas dos últimos commits do main.

O branch one precisa de uma reordenação e da exclusão do C5. O two precisa apenas de reordenação. O three precisa de um único commit!

Vamos deixar você descobrir como resolver esta tarefa -- mas não deixe de ver a nossa solução depois com o comando show solution.

Comandos:

# 1
git checkout one

# 2
git cherry-pick C4 C3 C2

# 3
git checkout two

# 4
git cherry-pick C5 C4 C3 C2

# 5
git branch -f three C2

Aprendendo Git Branching - Módulo Sortidos

Vitor Jr. — Thu, 08 Jun 2023 20:35:30 +0000

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

levels

Main

Módulo: Sortidos

1: Pegando um único commit

Dificuldade (pra mim!): fácil

Aqui está uma situação de acontece frequentemente com desenvolvedores: Estou tentando encontrar um bug, mas ele é escorregadio. Para auxiliar meu trabalho de detetive, eu coloco alguns comandos de debug e prints.
Todos esses comandos de debug e mensagens estão em seus próprios branches. Finalmente eu encontro o bug, corrijo!
O único problema é que agora eu preciso devolver o meu bugFix ao branch main. Se eu simplesmente der um fast-forward no main, então o main terminará contendo todos os comandos de debug, o que é indesejável.
Precisamos dizer ao git para copiar somente um dos commits. Esta situação é exatamente a mesma dos níveis anteriores a respeito de como mover trabalho -- podemos usar os mesmos comandos:

git rebase -i

git cherry-pick

2: Malabarismo com commits

Dificuldade (pra mim!): impossível, I have no idea what I'm doing

Aqui está outra situação que acontece com bastante frequência. Você fez algumas mudanças (newImage), além de um outro conjunto de mudanças (caption) que são relacionadas, de forma que elas estão empilhadas uma após a outra no seu repositório.
O complicado é que algumas vezes você precisa fazer uma pequena modificação em um commit mais antigo. Neste caso, o pessoal do design quer que modifiquemos um pouco as dimensões da imagem introduzida em newImage, apesar de esse commit estar mais para trás no nosso histórico!!
Superaremos essa dificuldade fazendo o seguinte:
- Reordenaremos os commits de forma que aquele que desejamos esteja no topo, com git rebase -i
- Usaremos o comando git commit --amend para fazer uma pequena modificação
- Vamos, então, reordenar os commits na mesma ordem que estavam anteriormente com git rebase -i
- Finalmente, moveremos o main para essa parte atualizada da árvore para finalizar o nível (usando o método de sua escolha)
Há muitas formas de alcançar o objetivo final (eu vejo o cherry-pick passando pela sua mente), e veremos mais delas depois, mas por enquanto foquemos nesta técnica.
Por último, preste atenção no estado do "objetivo" aqui -- como nós movemos os commits duas vezes, ambos ficam com um apóstrofo. Um apóstrofo adicional é colocado no commit que sofreu o "amend", o que nos dá a forma final da árvore
Tendo dito isto, posso avaliar a resposta baseado na estrutura e nas diferenças relativas de número de apóstrofos. Desde que o branch main da sua árvore tenha a mesma estrutura, e o número de apóstrofos seja igual a menos de uma constante, darei a você todos os pontos para esta tarefa.

Solução: YouTube

Comandos:

# 1
git rebase -i caption~2

# 2
# order: C3 -> C2

# 3
git commit --amend

# 4
git rebase -i caption~2

# 5
# order: C2''' -> C3''

# 6
git branch -f main caption

3: Malabarismo com commits #2

Dificuldade (pra mim!): por incrível que pareça, esse foi fácil

Como você viu no nível anterior, usamos rebase -i para reordenar os commits. Uma vez que o commit que queríamos mudar estava no topo, pudemos facilmente usar o --amend e depois reordená-lo de volta para obter nossa ordem preferida.
O único problema aqui é que há muita reordenação ocorrendo, o que pode introduzir conflitos de rebase. Vamos dar uma olhada em outro método, usando o git cherry-pick.
Lembre-se que o git cherry-pick copiará um commit de qualquer lugar na árvore sob o HEAD (desde que esse commit não seja um ancestral do HEAD).

4: Tags no Git

Dificuldade (pra mim!): fácil

Como você aprendeu nas lições anteriores, branches são fáceis de mover e geralmente vão se referindo a diferentes commits conforme você vai trabalhando no código. branches são facilmente mutáveis, frequentemente temporários, e estão sempre mudando.
Se este é o caso, você pode estar se perguntando se não existe uma forma de marcar permanentemente pontos históricos do projeto. Para coisas como grandes releases ou grandes merges, existe alguma forma de marcar commits com algo mais permanente que um branch?
As tags do Git foram criadas exatamente para esse caso de uso -- elas marcam de forma (relativamente) permanente certos commits como se fossem "milestones" em uma estrada, e você pode referenciá-las exatamente como faz com branches.
O mais importante, no entanto, é que elas nunca se movem sozinhas quando novos commits são criados. Você pode fazer "checkout" em uma tag e então completar trabalho nessa tag -- tags existem como âncoras na árvore de commits que estão atreladas a certos pontos.

5: Git Describe

Dificuldade (pra mim!): fácil

Devido ao fato de as tags servirem como "âncoras" tão boas no código, o Git tem um comando para descrever onde você está com relação à "âncora" (tag) mais próxima. Esse comando é chamado git describe!
O git describe pode ajudar a recuperar a sua orientação depois de você ter se movido muitos commits para trás ou para frente no histórico; isso pode acontecer depois de você completar um git bisect (uma busca para debug) ou quando se sentar no computador de um colega que acabou de voltar de férias.
O git describe é chamado da seguinte forma:

git describe <ref>

Onde <ref> é qualquer coisa que o git possa resolver como uma referência a um commit. Se você não especificar o ref, o Git usa simplesmente o commit atual (HEAD).
A saída do comando é mais ou menos assim:

<tag>_<numCommits>_g<hash>

Onde tag é a tag ancestral mais próxima no histórico, numCommits é o número de commits de distância da tag, e <hash> é o hash do commit sendo descrito.

Aprendendo Git Branching - Módulo Movendo trabalho por aí

Vitor Jr. — Thu, 08 Jun 2023 20:33:16 +0000

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

levels

Main

Módulo: Movendo trabalho por aí

1: Introdução ao `cherry-pick`

Dificuldade (pra mim!): fácil

O próximo conceito que vamos abordar é "movendo trabalho por aí" -- em outras palavras, veremos as formas como o desenvolvedor pode dizer "eu quero este trabalho aqui, e aquele ali" de formas precisas, eloquentes e flexíveis.
O primeiro comando desta série é o git cherry-pick. Ele é chamado da seguinte forma:

git cherry-pick <Commit1> <Commit2> <...>

Trata-se de uma forma bastante direta de dizer que você gostaria de copiar uma série de commits abaixo do seu local atual (HEAD).

2: Introdução ao rebase interativo

Dificuldade (pra mim!):

O cherry-pick é ótimo quando você sabe de antemão quais commits você quer (e você sabe os hashes correspondentes) -- é difícil bater a simplicidade que ele oferece.
Mas e quando você não sabe quais commits você quer? Felizmente o git pode te ajudar nesta situação também! Podemos usar o rebase interativo para isso -- trata-se da melhor forma de rever uma série de commits sobre os quais você está prestes a fazer um rebase.
O rebase interativo é simplesmente o comando rebase com a opção -i.
Se você incluir essa opção, o git abrirá uma interface para mostrar quais commits estão prestes a serem copiados abaixo do alvo do rebase. Ele também mostra os hashes e as mensagens dos commits, o que é ótimo para ter noção do que é o que.
No git "de verdade", a interface nada mais é que um arquivo aberto em um editor de texto (por exemplo o vim).
Quando a janela de rebase interativo abrir, você pode fazer 3 coisas diferentes:
- Você pode reordenar os commits simplesmente mudando sua ordem na interface (na nossa janela isso significa arrastar e soltar com o mouse).
- Você pode escolher simplesmente omitir alguns commits. Para isso, clique no botão pick -- deixar o pick desligado significa que você quer descartar o commit.
- Por fim, você pode "esmagar" (fazer squash) nos commits.

Aprendendo Git Branching - Módulo Acelerando

Vitor Jr. — Thu, 08 Jun 2023 15:33:08 +0000

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

levels

Main

Módulo: Acelerando

1: Solte a sua cabeça

Dificuldade (pra mim!): fácil

HEAD é um nome simbólico para o commit atualmente ativo (que sofreu checkout por último) -- é essencialmente o commit sobre o qual você está trabalhando no momento.
O HEAD sempre aponta para o commit mais recentemente copiado sobre a árvore de trabalho (arquivos do projeto).
Normalmente o HEAD aponta para o nome de um branch (por exemplo, bugFix). Quando você commita, o status do bugFix é alterado e essa mudança ocorre também sobre o HEAD.
Soltar o HEAD significa anexá-lo a um commit em vez de anexá-lo a um branch. Antes do estado solto ("detached"), é assim como se parece:

HEAD -> main -> C1

Depois do comando git checkout C1, fica:

HEAD -> C1

2: Referências relativas (`^`)

Dificuldade (pra mim!): fácil

Mover-se pela árvore do Git especificando o hash do commit pode se tornar um pouco entediante. No mundo real, você não terá à sua disposição essa bonita visualização da árvore ao lado do seu terminal, então você terá de usar o comando git log para ver os hashes.
Além disso, os hashes são geralmente muito maiores no mundo real. Por exemplo, o hash do commit que introduziu o nível de exercícios anterior é fed2da64c0efc5293610bdd892f82a58e8cbc5d8. Não é algo exatamente fácil de lembrar.
O que salva é que o Git é inteligente com os hashes. Ele só exige que você especifique a quantidade de caracteres do hash suficiente para identificar unicamente o commit.
Com referências relativas, você pode começar a partir de um ponto fácil de lembrar (como o branch bugFix ou o HEAD) e referenciar a partir dali.
Commits relativos são poderosos, mas vamos introduzir apenas dois tipos simples aqui:
- Mover para cima um commit por vez com ^
- Mover para cima um número de vezes com ~<num>
Vamos dar uma olhada no operador circunflexo (^) primeiro. Cada vez que você adicioná-lo a um nome de referência, você está dizendo ao Git para encontrar o pai do commit especificado.
Então, dizer main^ é equivalente a "o primeiro pai do main".
main^^ é o avô (ancestral de segunda geração) do main

3: Referências relativas #2 (`~`)

Dificuldade (pra mim!): difícil

Digamos que você queira se mover vários níveis para cima na árvore de commits. Pode ser entediante digitar ^ várias vezes, e por isso o Git possui também o operador til (~).
Um número pode ser passado (opcionalmente) após o operador til, especificando o número de ancestrais que você deseja subir.
Uma das situações mais comuns na qual eu uso referências relativas é quando quero trocar branches de lugar. Você pode redefinir diretamente o commit para o qual um branch aponta com a opção -f. Desta forma, o seguinte comando:

git branch -f main HEAD~3

Move (à força) o branch main 3 ancestrais acima do HEAD.

4: Referências relativas #3 (`~`)

Dificuldade (pra mim!): médio

Existem várias maneiras de reverter mudanças no Git. E assim como o ato de commitar, reverter mudanças no Git também tem um componente de baixo nível (a preparação, ou staging, de arquivos ou trechos de arquivos individuais) e um componente de alto nível (como as mudanças são, de fato, revertidas).
Há duas maneiras principais de desfazer mudanças no Git -- uma delas é usando git reset, e a outra é usando git revert. Vamos olhar cada uma delas na próxima janela
O comando git reset reverte mudanças movendo para trás no tempo (para um commit mais antigo) a referência do branch. Desta forma, você pode pensar nessa operação como uma "reescrita do histórico"; o git reset vai mover o branch para trás como se o commit nunca tivesse existido.
Embora o reset funcione muito bem em branches locais no seu próprio computador, o método utilizado de "reescrever o histórico" não funciona com branches remotos que outras pessoas estejam usando.
Para reverter mudanças e conseguir compartilhar essas mudanças com os outros, precisamos usar o git revert.
Quando usamos o revert um novo commit é criado A FRENTE na árvore. Isso é porque o novo commit C2' introduz mudanças -- acontece que as mudanças que ele introduz revertem exatamente aquelas do commit C2.
Com o revert, você pode fazer push das suas mudanças para compartilhá-las com os outros.

Aprendendo Git Branching - Módulo Sequência introdutória

Vitor Jr. — Thu, 08 Jun 2023 15:16:02 +0000

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

Aprendi git no dia a dia, e fazendo alguns cursos. Mas nunca estudei mais a fundo.
Decidi entender melhor como funciona toda essa parada de branch entre tantas outras palavrinhas que vemos durante o uso.
Pra isso, comecei com os exercícios no literalmente chamado Aprendendo Git Branching.
O que eu aprendi até o momento?

use commits curtos;
use pequenas branches;
não esqueça o checkout;

Sobre a ferramenta/site?

é possível exportar a sua 'árvore' usando o comando export tree e import tree;
é possível construir seu próprio com o comando build level e importar cenário com o comando import level;

levels

Main

Módulo: Sequência introdutória

1: Introdução aos commits no Git

Dificuldade (pra mim!): fácil

Um commit em um repositório git registra uma fotografia (snapshot) de todos os arquivos no seu diretório.
O Git tem por objetivo manter os commits tão leves quanto possível.
Ele pode (quando possível) comprimir um commit como um conjunto de mudanças (ou um "delta") entre uma versão do seu repositório e a seguinte.
O Git também mantém um histórico de quando ocorreu cada commit. É por isso que a maioria dos commits tem ancestrais acima de si.

2: Ramos (`branch`) no Git

Dificuldade (pra mim!): fácil

Branch no Git também são incrivelmente leves. Eles são simplesmente referências a um commit específico -- e nada mais.
Lembre-se do mantra:

branch early, and branch often

Devido a não existir sobrecarga de armazenamento / memória associada à criação de branchs, é mais fácil dividir logicamente o seu trabalho do que ter branches grandes e complexos.
Quando começarmos a misturar branches e commits, vamos ver como esses dois recursos combinam bem. Por enquanto, só lembre que um branch diz essencialmente "Quero incluir o trabalho deste commit e de todos os seus ancestrais".

3: Branches e Merge

Dificuldade (pra mim!): fácil

O primeiro método para combinar trabalho que vamos examinar é o git merge.
O merge do Git cria um commit especial que possui dois pais únicos.
Um commit com dois pais essencialmente significa "Quero incluir todo o trabalho deste pai aqui com o daquele outro pai ali, e com o do conjunto de todos os seus ancestrais."

4: Rebase no Git

Dificuldade (pra mim!): médio

A segunda forma de combinar trabalho entre branchs é o rebase. O rebase essencialmente pega um conjunto de commits, "copia" os mesmos, e os despeja em outro lugar.
Isso pode parecer confuso, mas a vantagem do rebase é que ele pode ser usado para construir uma sequência mais bonita e linear de commits.
O registro de commits (história do repositório) ficará muito mais limpa se for utilizado apenas rebase em vez de merge.

Módulo: Acelerando

1: Solte a sua cabeça

Dificuldade (pra mim!): fácil

HEAD é um nome simbólico para o commit atualmente ativo (que sofreu checkout por último) -- é essencialmente o commit sobre o qual você está trabalhando no momento.
O HEAD sempre aponta para o commit mais recentemente copiado sobre a árvore de trabalho (arquivos do projeto).
Normalmente o HEAD aponta para o nome de um branch (por exemplo, bugFix). Quando você commita, o status do bugFix é alterado e essa mudança ocorre também sobre o HEAD.
Soltar o HEAD significa anexá-lo a um commit em vez de anexá-lo a um branch. Antes do estado solto ("detached"), é assim como se parece:

HEAD -> main -> C1

Depois do comando git checkout C1, fica:

HEAD -> C1

Aprendendo Git Branching - Comandos

Vitor Jr. — Thu, 08 Jun 2023 15:12:39 +0000

Comandos utilizados e aprendidos na série Aprendendo Git Branching.

Comandos

`commit`

# cria um snapshot do trabalho atual
git commit

`branch`

# cria uma nova branch chamada newImage
git branch newImage

`checkout`

# cria a nova branch bugFix e altera para a mesma
git checkout -b bugFix

# C1: hash do commit
# faz checkout e aponta o head para o commit C1
git checkout C1

# sendo que a branch bugFix está em C4:
# 1-fazer checkout para a branch bugFix
# 2-fazer checkout para o commit C3
git checkout bugFix^

# sendo que HEAD e a branch main está em C4:
# 1-fazer checkout para a branch main
# 2-fazer checkout para o commit C0
git checkout HEAD~4

# sendo que HEAD e a branch main está em C7:
# 1-fazer checkout para o segundo pai do commit C7
# 2-fazer checkout para dois commits atrás do segundo pai
git checkout HEAD~^2~2

`cherry-pick`

# dados os commits C1, C2, C3, C4, C5, C6 e C7
# escolher apenas os commits C7, C3 e C5 nessa ordem
# para serem adicionados na branch main
git cherry-pick C7 C3 C5

`reset`

# move a referêcia para o commit anterior repo LOCAL
git reset HEAD~1

`revert`

# move a referêcia para o commit anterior repo REMOTO
git revert HEAD

`rebase`

# tendo feito o checkout para branch bugFix
# move o trabalho dessa branch para a main
git rebase main

# tendo a branch main como HEAD
# selecionar opções dentro dos útimos 3 commits
git rebase -i HEAD~3

`merge`

`tag`

# cria uma tag para o commit C1 com o nome v1.0
git tag v1.0 C1

`fetch`

`pull`

# faz o pull e rebase ao mesmo tempo
git pull --rebase

DEV Community: Vitor Jr.

Aprendendo Git Branching - Push & Pull - repositórios remotos no Git!

levels

Remote

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

1: Introdução a clonagem

Dificuldade (pra mim!): fácil

2: Branches remotos

Dificuldade (pra mim!): fácil

3: Git fetch

Dificuldade (pra mim!):

4: Git pull

Dificuldade (pra mim!):

5: Simulando trabalho em equipe

Dificuldade (pra mim!):

6: Git push

Dificuldade (pra mim!):

7: Histórico Divergente

Dificuldade (pra mim!):

8: Main bloqueado

Dificuldade (pra mim!):

Aprendendo Git Branching - Temas Avançados

levels

Main

Módulo: Temas avançados

1: Fazendo mais de 9000 rebases

Dificuldade (pra mim!): dificil

2: Especificando pais

Dificuldade (pra mim!): fácil

3: Espaguete de branches

Dificuldade (pra mim!): fácil

Aprendendo Git Branching - Módulo Sortidos

levels

Main

Módulo: Sortidos

1: Pegando um único commit

Dificuldade (pra mim!): fácil

2: Malabarismo com commits

Dificuldade (pra mim!): impossível, I have no idea what I'm doing

Solução: YouTube

3: Malabarismo com commits #2

Dificuldade (pra mim!): por incrível que pareça, esse foi fácil

4: Tags no Git

Dificuldade (pra mim!): fácil

5: Git Describe

Dificuldade (pra mim!): fácil

Aprendendo Git Branching - Módulo Movendo trabalho por aí

levels

Main

Módulo: Movendo trabalho por aí

1: Introdução ao cherry-pick

Dificuldade (pra mim!): fácil

2: Introdução ao rebase interativo

Dificuldade (pra mim!):

Aprendendo Git Branching - Módulo Acelerando

levels

Main

Módulo: Acelerando

1: Solte a sua cabeça

Dificuldade (pra mim!): fácil

2: Referências relativas (^)

Dificuldade (pra mim!): fácil

3: Referências relativas #2 (~)

Dificuldade (pra mim!): difícil

4: Referências relativas #3 (~)

Dificuldade (pra mim!): médio

Aprendendo Git Branching - Módulo Sequência introdutória

Sobre a ferramenta/site?

levels

Main

Módulo: Sequência introdutória

1: Introdução aos commits no Git

Dificuldade (pra mim!): fácil

2: Ramos (branch) no Git

Dificuldade (pra mim!): fácil

3: Branches e Merge

Dificuldade (pra mim!): fácil

4: Rebase no Git

Dificuldade (pra mim!): médio

Módulo: Acelerando

1: Introdução ao `cherry-pick`

2: Referências relativas (`^`)

3: Referências relativas #2 (`~`)

4: Referências relativas #3 (`~`)

2: Ramos (`branch`) no Git

`commit`

`branch`

`checkout`

`cherry-pick`

`reset`

`revert`

`rebase`

`merge`

`tag`

`fetch`

`pull`

`push`