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

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