git cherry-pick

Branches e merges

Aplicar as mudanças de commits específicos na branch atual

O comando 'git cherry-pick' aplica as mudanças introduzidas por um ou mais commits existentes na branch atual, criando um commit novo para cada um. Diferente de merge ou rebase, que trabalham com branches inteiras, o cherry-pick permite copiar commits específicos de forma seletiva. É valioso para levar hotfixes a branches de release, recuperar commits perdidos ou trazer funcionalidades específicas de uma branch para outra sem mesclar tudo. Cada commit copiado ganha um SHA novo - é uma cópia, não uma mudança de lugar. O cherry-pick é cirúrgico e preciso, dando controle fino sobre quais mudanças chegam à sua branch.

Sinopse

git cherry-pick [--edit] [-n] [-m <parent-number>] [-s] [-x] [--ff] [-S[<keyid>]] <commit>...
git cherry-pick (--continue | --skip | --abort | --quit)
[ ] opcional| ou<arg> valor a substituir... repetível--flag opção

Opções

Clique em uma opção para expandir

Iniciante (2)

Aplicar as mudanças ao diretório de trabalho e ao índice sem criar commit. Perfeito para juntar vários cherry-picks em um único commit.

Quando necessárioJuntar vários cherry-picks em um commit

Exemplo

git cherry-pick -n abc1234

Abrir o editor para mudar a mensagem antes do commit. Use quando quiser explicar por que o commit foi copiado.

Quando necessárioAcrescenta contexto à mensagem do commit copiado

Exemplo

git cherry-pick -e abc1234

Intermediário (5)

Retomar o cherry-pick depois de resolver os conflitos. Antes, prepare os arquivos resolvidos com 'git add'.

RecomendadoRetoma depois que você resolve e prepara os conflitos

Exemplo

git cherry-pick --continue

Cancelar o cherry-pick e voltar a branch ao estado de antes. Use quando os conflitos forem complexos demais ou você escolheu o commit errado.

RecomendadoCancela com segurança e restaura o estado de antes do cherry-pick

Exemplo

git cherry-pick --abort

Pular o commit atual e continuar com os commits restantes da sequência. As mudanças do commit pulado NÃO são aplicadas.

Quando necessárioPula um commit cujas mudanças você não precisa mais

Exemplo

git cherry-pick --skip

Acrescentar '(cherry picked from commit ...)' à mensagem do commit. Ajuda a rastrear a origem dos commits copiados.

RecomendadoRegistra o commit de origem — essencial para backports

Exemplo

git cherry-pick -x abc1234

Adicionar o trailer 'Signed-off-by' com o seu nome e e-mail. Alguns projetos exigem isso por questões legais ou de auditoria.

Quando necessárioSó se o projeto exigir linhas Signed-off-by

Exemplo

git cherry-pick -s abc1234

Avançado (2)

Manter commits que já eram vazios desde o início (mesma árvore do pai). Commits que ficam vazios porque as mudanças já existem ainda param o processo; use --empty=keep para eles.

Quando necessárioSó para commits que já eram vazios desde o início

Exemplo

git cherry-pick --allow-empty abc1234

Obrigatório no cherry-pick de commits de merge. Indica qual pai (1 ou 2) é a linha principal. Normalmente -m 1 para pegar as mudanças da branch mesclada.

Quando necessárioObrigatório para commits de merge; normalmente -m 1

Exemplo

git cherry-pick -m 1 abc1234

Especialista (2)

Usar a estratégia de merge indicada ao aplicar as mudanças. O padrão é 'ort' (ou 'recursive' em Git antigo). Não há forma curta: aqui -s significa --signoff.

Não recomendadoA estratégia ort padrão quase sempre é a certa

Exemplo

git cherry-pick --strategy=ort abc1234

Passar opções para a estratégia de merge. Comuns: 'theirs' (favorece as mudanças escolhidas), 'ours' (favorece o atual), 'patience' (diffs melhores).

Não recomendado-Xours / -Xtheirs descartam sem aviso um lado dos hunks em conflito

Exemplo

git cherry-pick -Xtheirs abc1234

Escolhendo a opção certa

Comparando git cherry-pick com comandos parecidos

Entender quando usar cherry-pick em vez de merge, rebase ou revert

ComandoAspectoCherry-pickOutro comando
ScopeSó commits específicosMerge: branch inteira / Rebase: branch toda
Creates new commitsSim - SHA novo, mesmo conteúdoMerge: commit de merge / Rebase: reescreve tudo
Original staysSim - original intocadoMerge: sim / Rebase: órfão
Use caseBackport, portar seletivamenteIntegrar branches completas
History effectCria mudanças duplicadasPreserva ou deixa linear
ConflictsPor commit durante o pickNo ponto de merge ou por commit do rebase

Exemplos de fluxos de trabalho

1
git checkout release-1.0

Trocar para a branch de release

2
git log main --oneline

Achar o hash do commit da correção

3
git cherry-pick -x abc123

Aplicar a correção com a referência de origem

4
git push origin release-1.0

Enviar a correção portada

1
git checkout main

Trocar para a branch main

2
git log feature --oneline

Revisar os commits da branch de funcionalidade

3
git cherry-pick abc123 def456

Escolher só os commits prontos

4
git push origin main

Enviar os commits escolhidos

1
git reflog

Achar o hash do commit no reflog

2
git checkout main

Trocar para a branch de destino

3
git cherry-pick abc123

Aplicar o commit órfão

1
git checkout target-branch

Trocar para a branch de destino

2
git cherry-pick A^..C

Aplicar os commits de A a C (inclusive)

3
git log --oneline

Conferir que os commits foram aplicados

Solução de problemas

"commit is a merge but no -m option was given"

Causa: Você está tentando fazer cherry-pick de um commit de merge sem dizer qual pai

Use -m 1 ou -m 2 para indicar o pai da linha principal

git cherry-pick -m 1 <merge-commit>

Conflitos durante o cherry-pick

Causa: As mudanças conflitam com a sua branch atual

Resolva os conflitos nos arquivos, faça git add e depois git cherry-pick --continue. Ou cancele com --abort

git add <resolved-files> && git cherry-pick --continue

"The previous cherry-pick is now empty"

Causa: As mudanças do commit já existem na sua branch

Rode 'git commit --allow-empty' para registrá-lo mesmo assim, ou 'git cherry-pick --skip' para pulá-lo

git cherry-pick --skip

O cherry-pick criou commits duplicados

Causa: As mesmas mudanças agora existem como commits diferentes em branches diferentes

Esse é o comportamento esperado. Use a opção -x para documentar a relação

git cherry-pick -x <commit>

Foi feito cherry-pick do commit errado

Causa: Você escolheu o SHA de commit errado

Se não foi enviado: git reset --hard HEAD~1. Se foi enviado: faça git revert do commit copiado

git reset --hard HEAD~1

O cherry-pick parece não ter efeito

Causa: O commit pode estar vazio ou as mudanças já foram aplicadas

Confira git diff HEAD~1 para ver as mudanças reais

git diff HEAD~1

Dicas e armadilhas

Boas práticas

  • ✓Use -x em backports para adicionar a referência '(cherry picked from commit ...)' à mensagem do commit
  • ✓Faça cherry-pick em ordem cronológica - commits dependentes devem ser aplicados do mais antigo ao mais novo para evitar conflitos
  • ✓Prefira merge em branches compartilhadas - cherry-pick cria commits duplicados, enquanto merge preserva o histórico
  • ✓Teste depois do cherry-pick - o commit pode funcionar no contexto original e falhar no novo
  • ✓Documente os cherry-picks nas mensagens com a opção -e, explicando por que o commit foi copiado
  • ✓Use --no-commit para juntar picks relacionados em um único commit mais limpo
  • ✓Considere usar git cherry em vez de log para achar commits que ainda não foram aplicados
  • ✓Em backports, sempre inclua o hash do commit original na mensagem para rastreabilidade

Erros comuns

  • ✗Esquecer o -m em commits de merge. Fazer cherry-pick de um commit de merge sem '-m 1' ou '-m 2' falha - é preciso dizer em relação a qual pai calcular o diff.
  • ✗Não preparar os arquivos resolvidos antes do --continue. Você precisa rodar 'git add' nos arquivos resolvidos antes de 'git cherry-pick --continue'.
  • ✗Esperar o mesmo hash de commit. O cherry-pick cria commits NOVOS com SHAs novos - ele copia mudanças, não move commits.
  • ✗Fazer cherry-pick de commits já aplicados. Isso causa conflitos ou commits vazios - confira antes com 'git log'.
  • ✗Escolher commits na ordem errada. Commits dependentes devem ser escolhidos do mais antigo ao mais novo, senão aparecem conflitos.
  • ✗Usar cherry-pick em branches públicas cria commits duplicados quando outras pessoas têm o original - prefira merge em branches compartilhadas.

Perguntas frequentes

A:

Não. O cherry-pick cria um commit NOVO com as mesmas mudanças, mas com outro SHA. O commit original fica onde estava.

A:

O hash de um commit no Git depende do conteúdo, do pai, do autor, da data e da mensagem. O cherry-pick mantém o autor e a data de autoria, mas o pai e a data do committer mudam, então o hash muda mesmo que as mudanças sejam idênticas.

A:

Sim! Liste-os: git cherry-pick A B C, ou use intervalos: git cherry-pick A^..C (inclui A e C).

A:

Use a opção -m: git cherry-pick -m 1 <merge-commit>. O número indica qual pai é a linha principal (normalmente 1).

A:

A..B exclui A (commits depois de A até B). A^..B inclui A (commits de A até B, inclusive).

A:

Se não foi enviado: git reset --hard HEAD~1. Se foi enviado: git revert <commit> para criar um commit que desfaz.

A:

Cherry-pick para commits específicos. Rebase para mover branches inteiras. Se você precisa da maioria dos commits de uma branch, o rebase é mais limpo.