Aprendendo Git Branching - Módulo Sortidos
Tags: git
Published: 2023-06-08 20:35:30

---
title: Aprendendo Git Branching - Módulo Sortidos
published: true
description: Série de posts sobre o site/aplicativo Aprendendo Git Branching. Aqui vou postar os comandos que aprendi e o que entendi de cada um.
tags: git
series: Learning Git Branching
---
**WIP**: A descrição e explicação dos comandos está sendo postada [aqui](https://dev.to/epochchrono/aprendendo-git-branching-comandos-24d2) 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](https://www.youtube.com/live/HU2ItgyhGNU?feature=share&t=3911)

  - Comandos:
<details>

```bash
# 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
```
</details>

##### 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.