Git no mundo real: stash, cherry-pick, blame e…

💡 TL;DR (Resumo)

Git no mundo real é sobre pragmatismo. git stash pausa trabalho sem bagunçar o histórico. git cherry-pick move commits cirurgicamente entre branches. git blame mostra contexto, não culpa. Hotfixes precisam de fluxo claro: branch separada, merge em main, depois em develop. Commits pequenos, nomes claros de branch e documentação do que foi feito economizam horas de treta em times grandes.

Nos tutoriais, Git parece simples: clone, commit, push, merge e abraço.

No mundo real tem:

Hotfix de produção no meio da sprint
PR gigantesca que ninguém quer revisar
Dev que some e deixa branch pela metade
Bug que está em produção mas "na minha máquina funciona"

Neste artigo vamos sair do Git de brinquedo e entrar no Git de guerra:

git stash para pausar bagunça sem perder trabalho
git cherry-pick para puxar commits cirurgicamente
git blame (e quando NÃO usar)
Estratégias para hotfix, backport e branches de suporte
Pequenos hábitos que evitam treta em time grande

Metade estratégia, metade mão na massa.

1. `git stash`: pausa, respira e volta depois

Você está no meio de uma feature, o PO aparece:

"Deu bug em produção, precisa corrigir agora."

Seu working directory está um caos. Ninguém quer commitar meia-boca só pra trocar de branch.

1.1. O básico de `stash`

bash

# guarda as mudanças atuais em um stash anônimo
git stash

# equivalente, de forma explícita
git stash push -m "WIP: feature X no meio do caos"

Depois, para listar:

bash

git stash list

# saída típica
stash@{0}: On feature-x: WIP: feature X no meio do caos
stash@{1}: On main: Ajustando logs

Para voltar o que estava guardado:

bash

# aplica e remove da pilha
git stash pop

# aplica mas mantém o stash na lista
git stash apply stash@{1}

1.2. Stash só de arquivos específicos

Você pode guardar só parte da bagunça:

bash

git stash push -m "Só front" src/frontend

Ou apenas o que já está no stage:

bash

git stash push -m "Só staged" --staged

1.3. Limpeza de stash

Acabou o dia, tem 15 stashes acumulados:

bash

# ver o conteúdo de um stash específico
git stash show -p stash@{2}

# apagar um específico
git stash drop stash@{2}

# apagar todos (cuidado)
git stash clear

Opinião polêmica: stash não é lixeira nem TODO list. Se você vive com 20 stashes abertos, está usando errado.

2. `git cherry-pick`: o bisturi do Git

git cherry-pick é o comando para quando você quer só um commit (ou alguns) de outro lugar.

Cenários clássicos:

Bugfix feito em develop que precisa ir para main agora
Você quer reaproveitar um commit de uma branch que morreu
Trouxe uma PR enorme, mas só 2 commits interessam

2.1. Uso básico

bash

# estando na branch onde quer aplicar o commit

git checkout main

git cherry-pick a1b2c3d

Isso vai criar um novo commit em main com as mesmas mudanças daquele hash.

2.2. Cherry-pick de vários commits

Sequência contínua:

bash

# inclui todos entre (a, b], exclusivo de a, inclusivo de b
git cherry-pick a1b2c3d..f6g7h8i

Lista específica:

bash

git cherry-pick a1b2c3d f6g7h8i 1122334

2.3. Lidando com conflitos

Normal: deu conflito. O Git vai te falar quais arquivos precisam ser resolvidos.

Fluxo:

bash

# 1. Resolve conflitos nos arquivos

# 2. Marca como resolvidos
git add <arquivos>

# 3. Continua o cherry-pick
git cherry-pick --continue

Se desistir no meio:

bash

git cherry-pick --abort

2.4. Quando NÃO usar cherry-pick

Pra simular merge
Como atalho pra copiar branch inteira

Se você está cherry-pickando 10+ commits, provavelmente é hora de pensar em:

Rebase ou
Merge decente

Dica de convivência: documente cherry-picks importantes na descrição do commit ou no PR. Quem for debugar no futuro vai agradecer.

3. `git blame`: ferramenta de código, não de RH

git blame mostra quem mexeu em cada linha de um arquivo.

bash

git blame src/app/service/user_service.js

Saída (simplificada):

bash

a1b2c3d (joao 2024-03-10 12:34:56)   if (user.isActive()) {
...

3.1. Uso inteligente do blame

Use para:

Entender o contexto de uma mudança
Ver em qual PR/commit algo foi introduzido
Descobrir quem pode ter contexto sobre um pedaço obscuro do código

Exemplo com mais contexto:

bash

git blame -L 50,90 src/app/service/user_service.js

Isso mostra apenas as linhas 50 a 90.

3.2. Quando blame vira tóxico

Se a cultura do time vira:

"Quem foi o infeliz que escreveu isso?"

Você tem um problema de time, não de Git.

Dica de dev raiz civilizado:

Use blame para chamar a pessoa pra conversar, não para prints no Slack.
Bug é mais sobre processo do que sobre indivíduo.

Opinião polêmica: se cada bug vira caça às bruxas no git blame, o bug não é do código, é da cultura.

4. Hotfixes, backports e branches de suporte

No mundo real, quase sempre existe o seguinte cenário:

Uma branch estável (main ou master)
Uma branch de desenvolvimento (develop ou similar)
Releases em produção que ainda precisam de suporte

4.1. Hotfix rápido em produção

Fluxo típico:

Você está em uma feature qualquer, stashada ou com work in progress.
Aparece um bug crítico em produção.

Passos:

bash

# guarda seu trabalho atual
git stash push -m "WIP feature-x"

# cria uma branch de hotfix a partir de main
git checkout main
git pull

git checkout -b hotfix/bug-critico-123

# corrige o bug, commita
git commit -am "Fix: corrige bug crítico 123"

git push -u origin hotfix/bug-critico-123

Depois:

Abre PR de hotfix/bug-critico-123 -> main
Após merge, faz merge ou cherry-pick do hotfix pra develop.

4.2. Backport para versões antigas

Você tem releases em produção (ex.: release/1.2, release/1.3).

Bug foi corrigido em main, mas precisa ir para release/1.2.

bash

# na branch release onde quer aplicar o fix
git checkout release/1.2

git cherry-pick <hash-do-commit-do-fix>

Documente no PR que aquele commit foi backportado para outras versões.

4.3. Branches de suporte de longo prazo

Times maiores costumam ter:

main: sempre pronto pra produção
develop: integração contínua de features
release/x.y: código em estabilização para uma versão específica
hotfix/x.y.z: correções rápidas para produção

Não precisa virar religião, mas ter nomes consistentes de branch já evita muita confusão.

5. Hábitos de Git que escalam em time grande

Alguns comportamentos simples fazem o Git deixar de ser vilão.

5.1. Commits pequenos e focados

Evite:

text

"ajustes gerais"
"várias coisas"
"fix"

Prefira:

text

"Refatora validação de senha"
"Adiciona log de erro no fluxo de pagamento"
"Corrige cálculo de desconto para cupons expirados"

Commits menores:

São mais fáceis de revisar
Quebram menos o git blame
Facilitam cherry-picks

5.2. Branches com propósito claro

Nomes que ajudam:

feature/<ticket>-descricao-curta
bugfix/<ticket>-descricao-curta
hotfix/<ticket>-descricao-curta

Exemplo:

text

feature/1234-listagem-produtos
bugfix/5678-carrinho-nao-salva
hotfix/9012-pagamento-em-loop

5.3. Rebase interativo para limpar a bagunça

Antes de abrir PR, considere dar uma limpada no histórico da sua branch:

bash

git rebase -i origin/main

No editor, você pode:

Reescrever mensagens de commit
Squash de commits "WIP"
Remover commits inúteis

Regra de sobrevivência: reescreva seu histórico à vontade antes do PR. Depois que mergeou na branch compartilhada, trate o histórico como imutável (salvo em casos especiais e combinados).

6. Checklist para Git em times grandes

Antes de culpar o Git, verifica:

Você sabe usar stash pra pausar trabalho?
Sabe fazer cherry-pick de um fix específico entre branches?
Usa blame pra entender contexto, não pra queimar colega?
Seu fluxo de hotfix está claro no time?
Seu histórico de commits é legível para humanos?

Se metade disso é novidade, tem espaço pra muito ganho rápido.

Curtiu esse passeio pelo Git da vida real?

Manda praquele amigo que ainda resolve hotfix copiando arquivo via FTP.

Me encontra no X/Twitter: @gss_62

#git #gittips

Git no mundo real: stash, cherry-pick, blame e sobrevivência em times grandes

✨TL;DR / Sumário Executivo

💡 TL;DR (Resumo)

1. `git stash`: pausa, respira e volta depois

1.1. O básico de `stash`

1.2. Stash só de arquivos específicos

1.3. Limpeza de stash

2. `git cherry-pick`: o bisturi do Git

2.1. Uso básico

2.2. Cherry-pick de vários commits

2.3. Lidando com conflitos

2.4. Quando NÃO usar cherry-pick

3. `git blame`: ferramenta de código, não de RH

3.1. Uso inteligente do blame

3.2. Quando blame vira tóxico

4. Hotfixes, backports e branches de suporte

4.1. Hotfix rápido em produção

4.2. Backport para versões antigas

4.3. Branches de suporte de longo prazo

5. Hábitos de Git que escalam em time grande

5.1. Commits pequenos e focados

5.2. Branches com propósito claro

5.3. Rebase interativo para limpar a bagunça

6. Checklist para Git em times grandes

Receba novos artigos