Aprendendo Git Branching - Módulo Sortidos

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.