Cherry-pick: o que é, como executar e comandos Git

O que é cherry-pick no Git

Cherry-pick é o comando git cherry-pick que pega alterações de um commit existente e as aplica como um novo commit no branch atual. O commit original permanece em seu lugar no seu próprio branch, enquanto uma cópia das alterações é criada no branch de destino. O comando é útil quando você precisa transferir uma correção específica sem mover um branch inteiro.

Sintaxe: git cherry-pick <commit-hash>. O Git analisa a diferença (diff) do commit especificado em relação ao seu pai e aplica essa diferença ao branch atual. Se vários arquivos forem alterados, todos são transferidos juntos. O comando também aceita intervalos: git cherry-pick A..B — todos os commits de A a B, excluindo A.

As flags ampliam suas capacidades: -n (--no-commit) aplica as alterações ao diretório de trabalho e ao índice sem criar um commit — útil quando você precisa combinar alterações de vários commits em um só. A flag -x adiciona uma linha (cherry picked from commit ...) à mensagem do commit, facilitando o rastreamento da origem das alterações no histórico.

# Cherry-pick de um único commit por hash
git cherry-pick a1b2c3d

# Cherry-pick de vários commits (sequencialmente)
git cherry-pick a1b2c3d e4f5g6h i6j7k8l

# Cherry-pick sem auto-commit
git cherry-pick -n a1b2c3d

# A flag -x adiciona referência ao commit original
git cherry-pick -x a1b2c3d

Quando usar cherry-pick

O cenário principal é transferir correções entre branches de release. Imagine: um bug crítico foi encontrado e corrigido no develop. O branch de release release/v2.1 já está separado e também contém este bug. Mesclar todo o develop no release traria muito código não finalizado, enquanto aplicar cherry-pick no único commit de correção é uma solução segura e precisa.

O segundo cenário é reverter alterações com restauração posterior. Se um commit foi revertido via git revert e depois se descobre que a reversão foi um erro — aplicar cherry-pick ao commit revertido restaura as alterações. Isso é mais correto do que reverter uma reversão porque não cria conflitos repetidos.

O terceiro cenário é combinar commits de diferentes branches de funcionalidade em um branch de teste para testes de integração. Em vez de mesclar vários branches inacabados (com código incompleto), você pode selecionar apenas os commits prontos de cada um e testar como funcionam juntos.

• Correções de bugs — transferir uma correção de develop para release sem código não finalizado.
• Hotfix — aplicar uma correção de um branch hotfix para main e develop simultaneamente.
• Desfazer uma reversão incorreta — aplicar cherry-pick ao commit revertido para restaurar as alterações.
• Testes — coletar commits selecionados de diferentes branches para testes de integração.

Cherry-pick vs rebase e merge

Cherry-pick difere de rebase e merge por trabalhar no nível de commits individuais em vez de branches inteiros. Enquanto o rebase transfere todos os commits de um branch e o merge combina dois branches, o cherry-pick seleciona apenas os necessários. Isso o torna uma ferramenta mais precisa, mas também mais manual.

Outra diferença é a autoria. Durante o cherry-pick, o Git por padrão preserva o autor do commit original, mas o committer se torna o usuário atual. A mensagem do commit pode rastrear a origem através da flag -x. Durante o rebase, tanto o autor quanto o committer se tornam o usuário atual com um novo hash.

Desempenho: aplicar cherry-pick a um único commit é mais rápido do que mesclar dois branches com muitos commits. Mas se você precisar transferir dezenas de commits, é melhor criar um branch temporário e fazer um rebase — será mais eficiente e não exigirá especificar dezenas de hashes.

Transferir vários commits

Vários commits podem ser transferidos com um único comando listando seus hashes separados por espaços: git cherry-pick A B C. O Git aplica os commits sequencialmente na ordem especificada. Se algum commit causar um conflito, o cherry-pick é pausado e o desenvolvedor deve resolver o conflito e depois continuar com git cherry-pick --continue.

Intervalo de commits: git cherry-pick A..B (todos os commits após A até B, excluindo A) e git cherry-pick A^..B (todos os commits de A inclusive até B). Os intervalos são convenientes quando você precisa transferir todos os commits de um branch sem a relação pai — por exemplo, ao mover uma funcionalidade completa de um branch antigo para um novo.

A flag --strategy determina como o Git aplica as alterações. Por padrão, a estratégia recursive é usada, mas você pode especificar ours ou theirs para selecionar automaticamente um lado do conflito. A flag --mainline é usada ao aplicar cherry-pick a um commit de merge — especifica o número do pai (1 ou 2) contra o qual o diff é calculado.

# Intervalo de commits cherry-pick
git cherry-pick develop~5..develop~2

# Cherry-pick de commit de merge (especificar pai)
git cherry-pick -m 1 m9n0o1p

# Usar estratégia theirs
git cherry-pick --strategy=recursive \
  --strategy-option=theirs a1b2c3d

# Continuar após resolução de conflitos
git cherry-pick --continue

Conflitos durante cherry-pick

Conflitos durante cherry-pick ocorrem quando as alterações do commit transferido afetam as mesmas linhas que foram alteradas no branch de destino. O Git pausa a execução, marca os arquivos em conflito e aguarda a resolução. No status, esses arquivos são exibidos como both modified.

Passos para resolver um conflito: abra o arquivo em conflito, encontre os marcadores de conflito (<<<<<<<, =======, >>>>>>>), edite o conteúdo, remova os marcadores, execute git add para os arquivos resolvidos e execute git cherry-pick --continue. Se o conflito não puder ser resolvido — git cherry-pick --abort cancela todo o cherry-pick, retornando o branch ao seu estado original.

Um problema comum: o commit já contém alterações equivalentes às existentes. Neste caso, o Git informa “nothing to commit” ou “empty commit” ao tentar cherry-pick. As flags --keep-redundant-commits e --empty=keep forçam o Git a criar um commit vazio para preservar a sequência, enquanto --skip permite pular esse commit.

# Conflito durante cherry-pick — parar
git cherry-pick a1b2c3d
# error: não foi possível aplicar a1b2c3d... mensagem do commit

# Resolver conflito → adicionar ao índice
git add src/conflicted_file.swift
git cherry-pick --continue

# Pular commit vazio (já aplicado)
git cherry-pick --skip

# Abortar completamente
git cherry-pick --abort

Melhores práticas de cherry-pick

Primeira regra: sempre verifique se o commit sendo transferido é autossuficiente. Se o commit A depende de alterações no commit B que não está sendo transferido, aplicar cherry-pick em A pode quebrar a compilação. Antes do cherry-pick, é útil verificar quais arquivos o commit alterou através de git show --stat <hash>.

Segunda regra: documente as operações de cherry-pick. Use a flag -x para que a mensagem do commit mantenha uma referência ao commit original. Isso ajudará durante a análise posterior do histórico a entender de onde veio a alteração. Sem -x, um cherry-pick parece um commit normal, e sua origem só pode ser determinada através de git log --graph.

Terceira regra: evite cherry-pick entre branches que divergiram muito. Se muito tempo passou desde que o commit foi criado e a base de código mudou significativamente, os conflitos serão numerosos e complexos. Nesses casos, é melhor reimplementar a correção no branch de destino — levará menos tempo do que resolver dezenas de conflitos.

• Cherry-pick apenas commits autossuficientes sem dependências externas.
• A flag -x é obrigatória para documentar a origem do commit na mensagem.
• Evite aplicar cherry-pick a commits antigos com grande divergência na base de código.
• CI/CD verifique a compilação após cherry-pick: um conflito pode não ter ocorrido, mas o código pode não compilar.
• Comentário no PR ao criar um pull request, indique quais commits foram transferidos via cherry-pick.